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This standard does not contain material related to the service delivery subsystem that is used to transport the 
commands, command parameter data, command response data, and status specified in this standard. 


Working Draft Automation/Drive Interface Commands - 2 (ADC - 2) 


T10/1741 -D Revision8 


10 July 2007 


American Approval of an American National Standard requires verification by ANSI that the require- 

National ments for due process, consensus, and other criteria for approval have been met by the 

Standard standards developer. Consensus is established when, in the judgment of the ANSI Board 

of Standards Review, substantial agreement has been reached by directly and materially 
affected interests. Substantial agreement means much more than a simple majority, but 
not necessarily unanimity. Consensus requires that all views and objections be 
considered and that effort be made toward their resolution. 

The use of American National Standards is completely voluntary; their existence does not 
in any respect preclude anyone, whether he or she has approved the standards or not, 
from manufacturing, marketing, purchasing, or using products, processes, or procedures 
not confirming to the standards. 

The American National Standards Institute does not develop standards and will in no 
circumstances give interpretation on any American National Standard in the name of the 
American National Standards Institute. Requests for interpretations should be addressed 
to the secretariat or sponsor whose name appears on the title page of this standard. 

CAUTION NOTICE: This American National Standard may be revised or withdrawn at any 
time. The procedures of the American National Standards Institute require that action be 
taken periodically to reaffirm, revise, or withdraw this standard. Purchasers of American 
National Standards may receive current information on all standards by calling or writing 
the American National Standards Institute. 


CAUTION: The developers of this standard have requested that holders of patents that may be required for 
the implementation of the standard disclose such patents to the publisher. However, neither the developers 
nor the publisher have undertaken a patent search in order to identify which, if any, patents may apply to this 
standard. 

As of the date of publication of this standard, following calls for the identification of patents that may be 
required for the implementation of the standard, notice of one or more such claims has been received. 

By publication of this standard, no position is taken with respect to the validity of this claim or of any rights in 
connection therewith. The known patent holder(s) has (have), however, filed a statement of willingness to 
grant a license under these rights on reasonable and nondiscriminatory terms and conditions to applicants 
desiring to obtain such a license. Details may be obtained from the publisher. 

No further patent search is conducted by the developer or publisher in respect to any standard it processes. 
No representation is made or implied that this is the only license that may be required to avoid infringement in 
the use of this standard. 


Published by 

American National Standards Institute 
11 West 42nd Street, New York, NY 10036 

Copyright 2007 by American National Standards Institute 
All rights reserved. 


Printed in the United States of America 


Working draft Automation/Drive Interface Commands - 2 (ADC - 2) 



10 July 2007 


T10/1741-D Revision8 


Contents 

Page 

Foreword.x 

Introduction.xiii 

1 Scope.1 

2 Normative References.2 

2.1 Normative references overview.2 

2.2 Approved references.2 

2.3 References under development.3 

3 Definitions, symbols, abbreviations, and conventions.4 

3.1 Definitions.4 

3.2 Symbols and abbreviations.6 

3.3 Keywords.7 

3.4 Conventions.8 

4 General.10 

4.1 Automation/drive interface model overview.10 

4.2 Device server interaction.11 

4.3 ADI bridging.13 

4.3.1 ADI bridging introduction.13 

4.3.2 Local SMC device server operation.13 

4.3.3 Remote SMC device server operation.14 

4.3.4 Bridging manager operation.14 

4.3.5 Caching SMC data and status.15 

4.4 Load and unload states.16 

4.4.1 Load states.16 

4.4.2 Unload states.18 

4.5 Sense data masking.19 

4.6 TapeAlert application client interface.19 

4.7 Medium Auxiliary Memory attributes.22 

4.8 DT device primary ports.22 

4.8.1 DT device primary port index.22 

4.8.2 Enabling and disabling DT device primary ports.22 

4.9 Sequential mode operation.23 

5 Commands for automation/drive interface devices.24 

5.1 Summary of commands for automation/drive interface devices.24 

5.2 NOTIFY DATA TRANSFER DEVICE command.27 

5.3 SET MEDIUM ATTRIBUTE command.29 

5.3.1 SET MEDIUM ATTRIBUTE command introduction.29 

5.3.2 SET MEDIUM ATTRIBUTE parameter list format.30 

5.3.3 SET MEDIUM ATTRIBUTE attribute format.31 

6 Parameters for automation/drive interface devices.32 

6.1 Log parameters.32 

6.1.1 Log parameters overview.32 

6.1.2 DT Device Status log page.33 

6.1.2.1 DT Device Status log page overview.33 

6.1.2.2 Very high frequency data log parameter.33 


Working draft Automation/Drive Interface Commands - 2 (ADC - 2) 





















T10/1741 -D Revision8 


10 July 2007 


6.1.2.3 Very high frequency polling delay log parameter.37 

6.1.2.4 DT device primary port status log parameter(s).38 

6.1.3 TapeAlert Response log page.41 

6.1.4 Requested Recovery log page.42 

6.1.4.1 Requested Recovery log page overview.42 

6.1.4.2 Recovery procedures log parameter.43 

6.1.5 Service Buffers Information log page.45 

6.2 Mode parameters.48 

6.2.1 Mode parameters overview.48 

6.2.2 ADC Device Server Configuration mode page.50 

6.2.2.1 Target Device subpage.50 

6.2.2.2 DT Device Primary Port subpage.52 

6.2.2.3 Logical Unit subpage.58 

6.2.2.4 Target Device Serial Number subpage.65 

6.3 Vital product data parameters.66 

6.3.1 Vital product data parameters overview and page codes.66 

6.3.2 Device Identification VPD page.67 

6.3.3 Manufacturer-assigned Serial Number VPD page.67 


Working draft Automation/Drive Interface Commands - 2 (ADC - 2) 









10 July 2007 T10/1741-D Revision 8 

Tables 

Page 

Table 1 - ISO and American numbering conventions examples.8 

Table 2 - Load states.16 

Table 3- Load states example.17 

Table 4- Unload states.18 

Table 5 - Additional conditions that cause TapeAlert state flags to be set to zero.20 

Table 6 - Command set for automation/drive interface.24 

Table 7 - NOTIFY DATA TRANSFER DEVICE command.27 

Table 8 - SET MEDIUM ATTRIBUTE command.29 

Table 9 - SET MEDIUM ATTRIBUTE parameter list format.30 

Table 10 - SET MEDIUM ATTRIBUTE attribute format.31 

Table 11 - attribute identifier field.31 

Table 12 - format field.31 

Table 13 - Log page codes.32 

Table 14 - DT Device Status log page.33 

Table 15 - DT Device Status log page parameter codes.33 

Table 17 - VHF data descriptor.34 

Table 16 - Very high frequency data log parameter format.34 

Table 18 - dt device activity field.36 

Table 19 - Very high frequency polling delay log parameter format.37 

Table 20 - DT device primary port status log parameter(s) format.38 

Table 21 - Port status data format by protocol identifier.38 

Table 22 - Fibre Channel port status data format.39 

Table 24 - Serial Attached SCSI port status data format.40 

Table 23 - SCSI parallel interface port status data format.40 

Table 25 - TapeAlert Response log page.41 

Table 26 - Requested Recovery log page.42 

Table 27 - Requested Recovery log page parameter codes.42 

Table 28 - Requested recovery log parameter format.43 

Table 29 - Recovery procedures.44 

Table 30 - Service Buffers Information log page.45 

Table 31 - Service buffer information log parameter format.46 

Table 32 - Service buffer information parameter codes.46 

Table 33 - Mode page codes.49 

Table 34 - Target Device subpage.50 

Table 35- mtdn field.51 

Table 36 - DT Device Primary Port subpage.52 

Table 37 - DT device primary port descriptor format.52 

Table 38 - Primary port descriptor by protocol identifier value.53 

Table 39 - Fibre Channel descriptor parameter format.53 

Table 40 - toplock bit, p2p bit, and topord bit interaction.54 

Table 41 - Effect of liv and rha bits.54 

Table 42- mpn field.55 

Table 43 - speed field.55 

Table 44 - Parallel SCSI descriptor parameter format.56 

Table 45- bmq field.56 

Table 46 - Serial Attached SCSI descriptor parameter format.57 

Table 47- mpi field.57 

Table 48- Logical Unit subpage.58 

Table 49 - RMC logical unit descriptor format.59 

Table 50- mlud field.60 

Table 51 - autoload mode field.61 

Table 52 - SMC logical unit descriptor format.62 


vii 


Working draft Automation/Drive Interface Commands - 2 (ADC - 2) 















T10/1741 -D Revision8 


10 July 2007 


Table 53 - ADC logical unit descriptor format.64 

Table 54 - Target Device Serial Number subpage.65 

Table 55- mpsn field.66 

Table 56 - ADC device VPD page codes.66 

Table 57 - Manufacturer-assigned Serial Number VPD page.67 


viii 


Working draft Automation/Drive Interface Commands - 2 (ADC - 2) 





10 July 2007 


T10/1741-D Revision8 


Figures 

Page 

Figure 1 - General Document Structure of SCSI.1 

Figure 2 - Example of an automation device and DT device relationship.11 

Figure 3 - Device server model.12 


ix 


Working draft Automation/Drive Interface Commands - 2 (ADC - 2) 






T10/1741 -D Revision8 


10 July 2007 


Foreword 


This foreword is not part of American National Standard INCITS.***:2007. 

This standard specifies the external behavior of a device server that defines itself as an automation/drive interface 
device in the device type field of the standard INQUIRY data. This device type is known as an automation/drive 
interface device. 

With any technical document there may arise questions of interpretation as new products are implemented. 
INCITS has established procedures to issue technical opinions concerning the standards developed by INCITS. 
These procedures may result in SCSI Technical Information Bulletins being published by INCITS. 

These Bulletins, while reflecting the opinion of the Technical Committee that developed the standard, are intended 
solely as supplementary information to other users of the standard. This standard, ANSI IINCITS.***:2007, as 
approved through the publication and voting procedures of the American National Standards Institute, is not 
altered by these bulletins. Any subsequent revision to this standard may or may not reflect the contents of these 
Technical Information Bulletins. 


Current INCITS practice is to make Technical Information Bulletins available through: 


INCITS Online Store 
managed by Techstreet 
1327 Jones Drive 
Ann Arbor, Ml 48105 Facsimile: 

or 

IHS 

15 Inverness Way East 
Englewood, CO 80112-5704 


http://www.techstreet.com/INCITS.html 
Telephone: 1-734-302-7801 or 
1-800-699-9277 
1-734-302-7811 


http://giobal.ihs.com/ 
Telephone: 1-303-792-2181 or 
1-800-854-7179 
Facsimile: 1-303-792-2192 


Requests for interpretation, suggestions for improvement and addenda, or defect reports are welcome. They 
should be sent to the INCITS Secretariat, InterNational Committee for Information Technology Standards, Infor¬ 
mation Technology Institute, 1250 Eye Street, NW, Suite 200, Washington, DC 20005-3922. 

This standard was processed and approved for submittal to ANSI by the InterNational Committee for Information 
Technology Standards (INCITS). Committee approval of the standard does not necessarily imply that all committee 
members voted for approval. At the time it approved this standard, INCITS had the following members: 

(Editor’s Note: Insert INCITS member list) 
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Introduction 

This standard is divided into the following clauses: 

Clause 1 is the scope. 

Clause 2 enumerates the normative references that apply to this standard. 

Clause 3 describes the definitions, symbols, abbreviations, and conventions used in this standard. 
Clause 4 describes an overview and model of the automation/drive interface device. 

Clause 5 describes the command set for automation/drive interface devices. 

Clause 6 describes the parameters for automation/drive interface devices. 
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American National Standard for Information Systems - 
Information Technology - 

Automation/Drive Interface Commands - 2 (ADC - 2) 

1 Scope 

This standard defines the model and command set extensions to facilitate operation of automation/drive interface 
devices. The clauses of this standard, implemented in conjunction with the applicable clauses of SPC-3, fully 
specifies the standard command set for automation/drive interface devices. 

The objective of this standard is to provide the following: 

a) permit an application client to communicate over a SCSI service delivery subsystem, with a logical unit that 
declares itself to be an automation/drive interface device in the peripheral device type field of the 
standard INQUIRY data (see SPC-3); 

b) define commands unique to the automation/drive interface device type; and 

c) define commands and parameters to manage the operation of the automation/drive interface device type 
and the operation of logical units of other specific device types that are present in the same device as the 
automation/drive interface logical unit. 

The following commands, parameter data, and features defined in previous versions of this standard are made 
obsolete by this standard: Linked commands. 

Figure 1 shows the relationship of this standard to the other standards and related projects in the SCSI family 
standards as of the publication of this standard. 


SCSI Architectural Model 
(e.g., SAM-3) 

Device-type specific 
command sets (e.g., SSC-2, 
this standard) 

Primary command set 
(e.g., SPC-3) 

SCSI transport protocols 
(e.g., SCSI encapsulation in ADT-2) 


Interconnects (e.g., ADT-2) 


Figure 1 — General Document Structure of SCSI 

Figure 1 is intended to show the general relationship of the documents to one another. Figure 1 is not intended to 
imply a relationship such as a hierarchy, protocol stack, or system architecture. It indicates the applicability of a 
standard to the implementation of a given transport. 

Commands in this standard do not require the use of a specific SCSI transport protocol. 
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2 Normative References 


2.1 Normative references overview 

The following standards contain provisions that, by reference in the text, constitute provisions of this standard. At 
the time of publication, the editions indicated were valid. All standards are subject to revision, and parties to agree¬ 
ments based on this standard are encouraged to investigate the possibility of applying the most recent editions of 
the standards listed below. 

Copies of the following documents may be obtained from ANSI: approved ANSI standards, approved and draft 
international and regional standards (ISO, IEC, CEN/CENELEC, ITUT), and approved and draft foreign standards 
(including BSI, JIS, and DIN). For further information, contact ANSI Customer Service Department at 
212-642-4900 (phone), 212-302-1286 (fax) or via the World Wide Web at http://www.ansi.org. 

Additional availability contact information is provided below as needed. 


2.2 Approved references 


ISO/IEC 

ISO/IEC 

ISO/IEC 

ISO/IEC 

ISO/IEC 

ISO/IEC 

ISO/IEC 

ISO/IEC 

ISO/IEC 

ISO/IEC 

ISO/IEC 

ISO/IEC 

ISO/IEC 


14776-412, SCSI Architecture Model - 2 (SAM-2) [ANSI INCUS 366-2003] 

14776-413, SCSI Architecture Model - 3 (SAM-3) [ANSI INCUS 402-2005] 

14776-452, SCSI Primary Commands - 2 (SPC-2) [ANSI INCUS 351-2001] 

14776-453, SCSI Primary Commands - 3 (SPC-3) [ANSI INCUS 408-2005] 

14776-332, SCSI Stream Commands - 2 (SSC-2) [ANSI INCUS 380-2003] 

14776-352, SCSI Media Changer Commands - 2 (SMC-2) [ANSI INCUS 382-2004] 
14776-364, Multimedia Commands - 4 (MMC-4) [ANSI INCUS 401-2005] 

14165-251, Fibre Channel Framing and Signaling Interface (FC-FS) [ANSI INCUS 373-2003] 
14165-122, Fibre Channel Arbitrated Loop - 2 (FC-AL-2) [ANSI INCUS 332-1999] 

14776-223, SCSI Fibre Channel Protocol - 3 (FCP-3) [ANSI INCUS 416-2006] 

14776-115, SCSI Parallel Interface - 5 (SPI-5) [ANSI INCUS 367-2003] 

14776-151, Serial Attached SCSI-1.1 (SAS-1.1) [ANSI INCUS 417-2006] 

14776-191, Automation/Drive Interface, Transport Protocol (ADT) [ANSI INCUS 406-2005] 
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2.3 References under development 

At the time of publication, the following referenced standards were still under development. For information on the 
current status of the document, or regarding availability, contact the relevant standards body or other organization 
as indicated. 

ISO/I EC 14776-454, SCSI Primary Commands - 4 (SPC-4) [T10/1731-D] 

ISO/IEC 14776-333, SCSI Stream Commands - 3 (SSC-3) [T10/1611-D] 

ISO/I EC 14776-352, SCSI Media Changer Commands - 3 (SMC-3) [T10/1730-D] 

ISO/IEC 14776-192, Automation/Drive Interface, Transport Protocol - 2 (ADT-2). [T10/1742-D] 
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3 Definitions, symbols, abbreviations, and conventions 


3.1 Definitions 

3.1.1 accessible state: The state of a device server in which it is capable of responding to a command with any 
combination other than CHECK CONDITION status with the sense key set to NOT READY. 

3.1.2 ADC device server: A device server (see 3.1.17) that reports the value 12h in the peripheral device type 
field of its standard INQUIRY data (see SPC-3). 

3.1.3 ADC logical unit: A logical unit (see 3.1.23) containing an ADC device server (see 3.1.2). 

3.1.4 ADI port: A port used to connect an automation device (see 3.1.9) and a DT device (see 3.1.15), that is not 
a DT device primary port (see 3.1.16) and not an automation device primary port (see 3.1.10). It supports a 
transport protocol that passes SCSI requests and SCSI responses (e.g., ADT or USB). 

3.1.5 additional sense data: The combination of values in an asc field and an ascq field (see 5.2). 

3.1.6 ADT port: An ADI port that implements ADT. 

3.1.7 application client: An object that is the source of commands and task management function requests (see 
SAM-3). 

3.1.8 automation application client: In an automation device, the application client of the ADC device server in 
the DT device (see 4.1). 

3.1.9 automation device: A device containing one or more SMC device servers (see SMC-2) or equivalent, one 
or more automation application clients, and one or more ports to access a DT device (e.g., an ADI port). An 
automation device may contain one or more automation device primary ports (see 4.1). 

3.1.10 automation device primary port: A SCSI target port or a SCSI target/initiator port (see SAM-3) in an 
automation device (see 3.1.9). 

3.1.11 bridging: A DT device (see 3.1.15) facilitating invocation of commands or task management requests on 
the remote SMC logical unit (see 4.3). 

3.1.12 bridging manager: In a DT device implementing bridging (see 4.3), the application client of the remote 
SMC device server (see 3.1.33). 

3.1.13 byte: A sequence of eight contiguous bits considered as a unit. 

3.1.14 contingent allegiance: An optional condition of a task set following the return of a CHECK CONDITION 
status (see SAM-2). 

3.1.15 data transfer (DT) device: A device containing an RMC device server, an ADC device server, one or 
more ports to access an automation device (e.g., an ADI port), and one or more DT device primary ports (see 4.1). 
A data transfer device may contain a bridging manager and local SMC device server (see 4.3). 

3.1.16 data transfer (DT) device primary port: A SCSI target port in a data transfer device (see 3.1.15). 

3.1.17 device server: An object within the logical unit that processes SCSI tasks according to the rules for task 
management (see SAM-3). 
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3.1.18 field: A group of one or more contiguous bits. 

3.1.19 l_T nexus: A nexus that exists between a SCSI initiator port and a SCSI target port (see SAM-3). 

3.1.20 l_T_L nexus: A nexus that exists between a SCSI initiator port, a SCSI target port, and a logical unit (see 
SAM-3). This relationship extends the prior l_T nexus. 

3.1.21 local SMC device server: The SMC device server in a DT device implementing bridging (see 4.3). 

3.1.22 local SMC logical unit: An SMC logical unit (see 3.1.44) in a DT device containing a local SMC device 
server (see 3.1.21). 

3.1.23 logical unit: A SCSI target device object, containing a device server and task manager, that implements a 
device model and manages tasks to process commands sent by an application client (see SAM-3). 

3.1.24 logical unit number (LUN): An identifier for a logical unit. 

3.1.25 logical unit reset: A logical unit action in response to a logical unit reset event in which the logical unit 
performs the operations described in SAM-3. 

3.1.26 logical unit reset event: An event that triggers a logical unit reset from a logical unit (see SAM-3). 

3.1.27 medium: The operational substrate and its carrier that is removable from a DT device. 

3.1.28 nexus: A relationship between two SCSI devices, and the SCSI initiator port and SCSI target port objects 
within those SCSI devices. 

3.1.29 not accessible state: The state of a device server in which it is only capable of responding to a command 
with CHECK CONDITION status with the sense key set to NOT READY. 

3.1.30 object: An architectural abstraction that encapsulates data types, services, or other objects that are 
related in some way. 

3.1.31 physical device: An object in a SCSI target device that performs operations on a medium (e.g., reading, 
writing, loading, and unloading). See SSC-3. 

3.1.32 ready state: A state where a logical unit is able to process a medium-access command without returning 
CHECK CONDITION status with the sense key set to NOT READY. 

3.1.33 remote SMC device server: The SMC device server in an automation device that receives commands via 
a DT device implementing bridging (see 4.3). 

3.1.34 remote SMC logical unit: An SMC logical unit (see 3.1.44) in an automation device containing a remote 
SMC device server (see 3.1.33). 

3.1.35 removable medium commands (RMC): A generic term for a command set supporting removable media 
(e.g., SSC-2 or MMC-4). 

3.1.36 RMC device server: A device server (see 3.1.17) that supports removable medium commands (see 
3.1.35). 

3.1.37 RMC logical unit: A logical unit (see 3.1.23) containing an RMC device server (see 3.1.36). 
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3.1.38 SCSI initiator device: A SCSI device containing application clients and SCSI initiator ports that originates 
device service and task management requests to be processed by a SCSI target device and receives device 
service and task management responses from SCSI target devices. When used this term refers to SCSI initiator 
devices or SCSI target/initiator devices that are using the SCSI target/initiator port as a SCSI initiator port (see 
SAM-3). 

3.1.39 SCSI initiator port: A SCSI initiator device object that acts as the connection between application clients 
and the service delivery subsystem through which requests, indications, responses, and confirmations are routed. 
In all cases when this term is used it refers to an initiator port or a SCSI target/initiator port operating as a SCSI 
initiator port (see SAM-3). 

3.1.40 SCSI target device: A SCSI device containing logical units and SCSI target ports that receives device 
service and task management requests for processing and sends device service and task management responses 
to SCSI initiator devices. When used this term refers to SCSI target devices or SCSI target/initiator devices that are 
using the SCSI target/initiator port as a SCSI target port (see SAM-3). 

3.1.41 SCSI target port: A SCSI target device object that contains a task router and acts as the connection 
between device servers and task managers and the service delivery subsystem through which indications and 
responses are routed. When this term is used it refers to a SCSI target port or a SCSI target/initiator port operating 
as a SCSI target port (see SAM-3). 

3.1.42 sense masking timeout value (SM_TOV): A period of time for which a DT device masks sense data (see 
4.5). 

3.1.43 SMC device server: A device server (see 3.1.17) that reports the value 08h in the peripheral device type 
field of its standard INQUIRY data (see SPC-3). 

3.1.44 SMC logical unit: A logical unit (see 3.1.23) containing an SMC device server (see 3.1.Y). 

3.1.45 storage element: A component of a medium changer device used only for storage of a medium (see 
SMC-2). 

3.1.46 task: An object within the logical unit representing the work associated with a command. A task consists of 
one initial connection and zero or more physical or logical reconnections, all pertaining to the task. 

3.1.47 task management request: A request that a task management function be performed (see SAM-3). 

3.1.48 task set: A group of tasks within a logical unit (see 3.1.23), whose interaction is dependent on the task 
management and auto-contingent allegiance rules (see SAM-3) and the contingent allegiance rules (see SAM-2). 

3.1.49 vendor-specific (VS): Something (e.g., a bit, field, code value) that is not defined by this standard and 
may be used differently in various implementations. 

3.1.50 zero: A false signal value or a false condition of a variable. 


3.2 Symbols and abbreviations 

= or EQ equal 

ADC Automation/Drive Interface - Commands 

ADC-2 Automation/Drive Interface - Commands - 2 

ADI Automation/Drive Interface 

ADT Automation/Drive Interface - Transport Protocol 
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ADT-2 

Automation/Drive Interface - Transport Protocol - 2 

DT 

data transfer (e.g., DT device) 

FC-AL-2 

Fibre Channel Arbitrated Loop (see clause 2) 

FC-FS 

Fibre Channel Framing and Signaling (see clause 2) 

FCP-3 

Fibre Channel Protocol-3 

Gb/sec 

gigabits per second 

LSB 

least significant bit 

LUN 

logical unit number 

MAM 

medium auxiliary memory (see SPC-3) 

MSB 

most significant bit 

MMC-4 

Multimedia Commands - 4 

RMC 

removable medium commands (see 3.1.35) 

Rsvd 

reserved 

SAM-2 

SCSI Architecture Model - 2 

SAM-3 

SCSI Architecture Model - 3 

SAS-1.1 

Serial Attached SCSI -1.1 

SCSI 

Small Computer System Interface 

SM TOV 

sense masking timeout value (see 4.5) 

SMC 

SCSI Media Changer Commands 

SMC-2 

SCSI Media Changer Commands - 2 

SMC-3 

SCSI Media Changer Commands - 3 

SPC-2 

SCSI Primary Commands - 2 

SPC-3 

SCSI Primary Commands - 3 

SPC-4 

SCSI Primary Commands - 4 

SPI-5 

SCSI Parallel Interface - 5 (see clause 2) 

SSC 

SCSI Stream Commands 

SSC-2 

SCSI Stream Commands - 2 

SSC-3 

SCSI Stream Commands - 3 

VHF 

very high frequency (e.g. VHF data) 

VPD 

vital product data (see SPC-3) 

VS 

vendor-specific (see 3.1.49) 


3.3 Keywords 

3.3.1 invalid: A keyword used to describe an illegal or unsupported bit, byte, word, field or code value. Receipt of 
an invalid bit, byte, word, field or code value shall be reported as an error. 

3.3.2 mandatory: A keyword indicating an item that is required to be implemented as defined in this standard to 
claim compliance with this standard. 

3.3.3 may: A keyword that indicates flexibility of choice with no implied preference. 

3.3.4 may not: Keywords that indicate flexibility of choice with no implied preference. 

3.3.5 obsolete: A keyword indicating that an item was defined in prior SCSI standards but has been removed 
from this standard. 

3.3.6 optional: A keyword that describes features that are not required to be implemented by this standard. 
However, if any optional feature defined by this standards is implemented, then it shall be implemented as defined 
in this standard. 
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3.3.7 reserved: A keyword referring to bits, bytes, words, fields and code values that are set aside for future 
standardization. Their use and interpretation may be specified by future extensions to this or other standards. A 
reserved bit, byte, word or field shall be set to zero, or in accordance with a future extension to this standard. 
Recipients are not required to check reserved bits, bytes, words or fields for zero values. Receipt of reserved code 
values in defined fields shall be reported as an error. 

3.3.8 shall: A keyword indicating a mandatory requirement. Designers are required to implement all such require¬ 
ments to ensure interpoperability with other products that conform to this standard. 

3.3.9 should: A keyword indicating flexibility of choice with a preferred alternative; equivalent to the phrase "it is 
recommended.” 


3.4 Conventions 

Certain words and terms used in this American National Standard have a specific meaning beyond the normal 
English meaning. These words and terms are defined either in clause 3 or in the text where they first appear. 
Names of signals, phases, messages, commands, statuses, sense keys, additional sense codes, and additional 
sense code qualifiers are in all uppercase (e.g., REQUEST SENSE), names of fields are in small uppercase (e.g., 
parameter list length), lower case is used for words having the normal English meaning. 

Fields containing only one bit are usually referred to as the name bit instead of the name field. 

A binary number is represented in this standard by any sequence of digits comprised of only the Western-Arabic 
numerals 0 and 1 immediately followed by a lower-case b (e.g., 0101b). Underscores or spaces may be included in 
binary number representations to increase readability or delineate field boundaries (e.g., 0 0101 1010b or 
0_01011010b). 

A hexadecimal number is represented in this standard by any sequence of digits comprised of only the 
Western-Arabic numerals 0 through 9 and/or the upper-case English letters A through F immediately followed by a 
lower-case h (e.g., FA23h). Underscores or spaces may be included in hexadecimal number representations to 
increase readability or delineate field boundaries (e.g., B FD8C FA23h or B_FD8C_FA23h). 

A decimal number is represented in this standard by any sequence of digits comprised of only the Western-Arabic 
numerals 0 through 9 not immediately followed by a lower-case b or lower-case h (e.g., 25). 

When the value of the bit or field is not relevant, x or xx appears in place of a specific value. 

This standard uses the ISO convention for representing decimal numbers (e.g., the thousands and higher multiples 
are separated by a space and a comma is used as the decimal point). Table 1 shows some examples of decimal 
numbers represented using the ISO and American conventions. 

Table 1 — ISO and American numbering conventions examples 


ISO 

American 

0,6 

0.6 

3,141 592 65 

3.14159265 

1 000 

1,000 

1 323 462,95 

1,323,462.95 
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Lists sequenced by letters (e.g., a-red, b-blue, c-green) show no priority relationship between the listed items. 
Numbered lists (e.g., 1-red, 2-blue, 3-green) show a priority ordering between the listed items. 

If a conflict arises between text, tables, or figures, the order of precedence to resolve the conflicts is text; then 
tables; and finally figures. Not all tables or figures are fully described in the text. Tables show data format and 
values. 

Notes and examples do not constitute any requirements for implementors. 
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4 General 


4.1 Automation/drive interface model overview 

An Automation/Drive Interface Commands - 2 (ADC-2) device server provides the means for an automation device 
(e.g., a media changer) to monitor and control a data transfer (DT) device (e.g., a removable medium device such 
as a tape drive). 

An automation device contains: 

a) an SMC logical unit, which controls a mechanism to move storage media among DT devices and storage 
elements; 

b) zero or more automation device primary ports, through which the SMC logical unit receives SCSI 
commands or task management requests; 

c) an automation application client (see 3.1.8); and 

d) one or more ports through which the automation application client transmits SCSI requests to and receives 
SCSI responses from the ADC device server in the DT device. 

A DT device contains: 

a) an ADC device server; 

b) an RMC device server (e.g., an SSC device server), which processes tasks from application clients 
performing write and read operations; 

c) an optional SMC device server and corresponding bridging manager (see 4.3); and 

d) one or more ports through which the device servers and bridging manager contained within the DT device 
pass SCSI requests and SCSI responses. At least one of these ports shall be a DT device primary port 
(see 3.1.16). On of these ports may bean ADI port (see 3.1.4). 

The automation application client may perform one or more of the following operations: 

a) configure the DT device's operational parameters (e.g., SCSI Port ID, Fibre Channel target device name, 
and Autoload mode); 

b) enable or disable the DT device primary ports (e.g., Parallel SCSI or Fibre Channel); 

c) determine the DT device's status, including the position of the removable medium and whether a medium 
access command is in process; or 

d) cause the DT device to unload or load a medium, even if its RMC device server is reserved by an appli¬ 
cation client (see 4.2). 

These operations are performed by invoking various commands and task management requests on the ADC 
logical unit. The application client within the automation device that invokes these requests is called the automation 
application client. Communication between device servers within the automation device and the automation appli¬ 
cation client are outside the scope of this standard. 

Figure 2 shows an example hardware view of the relationship between an automation device and DT devices using 
ADT transport protocol interfaces. 
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Medium 
T ransport 
Element 



ADI Port (optional) 
ADI Port (optional) 


Import / Export Element 


Storage Elements 


DT Device 
Primary Port(s) 


ADI Port (optional) 


DT Device 
i Primary Port(s) 


ADI Port (optional) 


Automation Device Primary Port (optional) 


Figure 2 — Example of an automation device and DT device relationship 


4.2 Device server interaction 

Figure 3 shows: 

a) an automation device with an automation application client and a remote SMC device server; and 

b) a DT device with an RMC device server, an ADC device server, and an optional local SMC device server 
(see 4.3). 

Because the RMC and ADC device servers coexist within a single target device and serve the same physical 
device, they interact with each other in various ways. 

If enabled (see 6.2.2.3.2), then the RMC device server shall be accessible as a logical unit through a DT device 
primary port. If the DT device contains an ADI port, then the RMC device server should be accessible as a logical 
unit through an ADI port, and may support asymmetric logical unit access (see SPC-3). 
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The ADC device server may be accessible as a logical unit through a DT device primary port. If the DT device does 
not contain an ADI port, then the ADC device server shall be accessible as a logical unit through a DT device 
primary port. If the DT device contains an ADI port, then the ADC device server shall be accessible as a logical unit 
through an ADI port. 

PREVENT ALLOW MEDIUM REMOVAL commands (see SPC-3) issued to the RMC device server shall not affect 
the ADC device server. 

Sense data reported by the RMC device server may be masked (see 4.5) for a period of time while the automation 
device is in the process of loading a medium. The NOTIFY DATA TRANSFER DEVICE command (see 5.2) 
provides a mechanism for the automation application client to indicate that the load attempt has ended in a failure 
and the RMC device server that was masking sense data changes shall resume reporting sense data for the 
failure. 



Figure 3 — Device server model 

Since the RMC and ADC device servers share the same physical device, operations related to the physical device 
are cause for interaction between the RMC and ADC device servers. Unit attention conditions shall be established 
by both the RMC and ADC device servers for causes based on the shared physical device (e.g., pressing an eject 
button on the physical device). Unit attention conditions shall not be propagated across both the RMC and ADC 
device servers for causes that are strictly within the domain of one device server. 

The ADC device server shall not support reservations. The ADC device server avoids reservation conflicts with 
other device servers since reservations held against one device server do not affect other device servers. 

NOTE 1 This approach allows the automation application client to interact with the physical device via the ADC 
device server without a conflict due to reservations on other device servers. 

The ADC device server supports mode pages that affect the RMC device server (see 6.2.2.3.2). The ADC mode 
pages override some mode parameters of the RMC device server (e.g., load or unload behavior). 

Some commands supported by the ADC device server are dependent upon the readiness of the removable 
medium (see table 6). The response to a TEST UNIT READY command (see SPC-3) issued to the ADC device 
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server indicates the readiness of the removable medium. The ADC device server shall establish a unit attention 
condition with an additional sense code of NOT READY TO READY CHANGE, MEDIUM MAY HAVE CHANGED 
based on the transition from not ready to ready of the removable medium. 

A LOAD UNLOAD command (see SSC-2) processed by the ADC device server may affect the ready state (see 
3.1.32) of the RMC device server and shall cause the RMC device server to establish appropriate unit attention 
condition. A LOAD UNLOAD command processed by the RMC device server may affect the ready state of the 
ADC device server and shall cause the ADC device server to establish appropriate unit attention condition. The 
interaction between the ADC task set and other task sets within the DT device are vendor-specific. 

The RMC and ADC device servers maintain independent TapeAlert flags (see 4.6) and return them to application 
clients. Retrieving the TapeAlert flag information from the ADC device server has no impact on the TapeAlert flags 
reported by the RMC device server. Retrieving the TapeAlert flag information from the RMC device server has no 
impact on the TapeAlert flags reported by the ADC device server. 

Communication between the application clients and device servers within a DT device, and application clients and 
device servers and the DT device itself are outside the scope of this standard. 


4.3 ADI bridging 

4.3.1 ADI bridging introduction 

The DT device may support ADI bridging for the automation device. When ADI bridging is enabled via the enable 
bit of the SMC Logical Unit descriptor (see 6.2.2.3.3), the DT device shall contain the bridging manager and the 
local SMC device server (see figure 3). The DT device shall report to its DT device primary port(s) a local SMC 
logical unit (see 3.1.22), and the automation device shall report a remote SMC logical unit (see 3.1.34) to the 
automation device ADI port. The local SMC logical unit may be accessible through the DT device ADI port, and 
may support asymmetric logical unit access (see SPC-3). 

The local SMC logical unit receives a command or task management request via a DT device primary port. In 
processing the command or task management request, the local SMC logical unit may require the automation 
device to perform additional processing. To perform this addition processing, the local SMC logical unit passes 
requests to an application client in the DT device (i.e., the bridging manager). This communication is performed by 
means outside the scope of this standard. Using the ADI ports on the DT device and automation device, the 
bridging manager then invokes commands or task management requests on the remote SMC logical unit that 
resides in the automation device. 

As a result some or all commands and task management requests addressed to the local SMC logical unit are 
passed to the remote SMC logical unit through the ADI port. 

4.3.2 Local SMC device server operation 

ADI bridging is enabled and disabled via the SMC Logical Unit descriptor of the ADC Device Server Configuration 
mode page implemented by the ADC device server (see 6.2.2.3.3). The descriptor specifies the logical unit number 
of the corresponding local SMC device server. When bridging is disabled, the SMC logical unit shall not be 
included in the logical unit inventory (see SPC-3) and shall be considered an incorrect logical unit by the task 
routers (see SAM-3). 

The local SMC device server shall support commands as required by the SCSI Media changer device type. If the 
transport protocol connecting the bridging manager and the remote SMC logical unit does not carry information 
about which l_T nexus originated a SCSI command or task management request, then the remote SMC device 
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server is not able to implement the complete set of commands. As a result, the local SMC logical unit shall service 
commands and task management functions that require knowledge of the originating initiator port. 

If any of the following commands are supported, then they shall be processed by the local SMC device server and 
not passed through to the remote SMC device server: 

a) RESERVED) and RESERVE(IO) (see SPC-2); 

b) RELEASED) and RELEASE(IO) (see SPC-2); 

c) PERSISTENT RESERVE IN (see SPC-3); 

d) PERSISTENT RESERVE OUT (see SPC-3); 

e) REPORT LUNS (see SPC-3); or 

f) REQUEST SENSE (see SPC-3). 

The local SMC device server shall not support element reservations in the RESERVE(6), RELEASE(6), 
RESERVED 0), and RELEASE(IO) commands. 

The local SMC device server shall also perform the following actions: 

a) check for reservation conflicts on all commands and return RESERVATION CONFLICT status on all 
commands that violate reservation rules (see SPC-3); 

b) manage unit attention conditions established for multiple initiator ports. If the local SMC device server 
detects that a unit attention condition is pending for an initiator port when a new command is received, the 
local SMC device server shall return CHECK CONDITION status for the command; and 

c) save sense data on a per l_T nexus basis, if a DT device primary port uses contingent allegiance (see 
SAM-2). 

The local SMC device server may augment information returned by the remote SMC device server based on infor¬ 
mation known only by the local SMC device server (e.g., Device Identification VPD page identification descriptors 
with an association field set to 01b (i.e., target port) and supported operation codes). 

The local SMC device server may process the following commands without passing them through to the remote 
SMC device server: 

a) REPORT SUPPORTED OPERATION CODES (see SPC-3); and 

b) REPORT SUPPORTED TASK MANAGEMENT FUNCTIONS (see SPC-3). 

4.3.3 Remote SMC device server operation 

The remote SMC device server shall not support any protocol-specific mode pages or protocol-specific log pages. 

The remote SMC device server shall not report Device Identification VPD page identification descriptors with an 
association field set to 01b (i.e., target port). 

The automation application client shall report all unit attention conditions established in the remote SMC device 
server shall for all initiator ports to the ADC device server using the NOTIFY DATA TRANSFER DEVICE command 
(see 5.2). 

4.3.4 Bridging manager operation 

ADI bridging is enabled and disabled via the SMC Logical Unit descriptor of the ADC Device Server Configuration 
mode page implemented by the ADC device server (see 6.2.2.3.3). The descriptor specifies the logical unit number 
of the corresponding remote SMC device server. 
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If the bridging manager receives a response from the remote SMC device server with a CHECK CONDITION 
status with the sense key set to UNIT ATTENTION, then the bridging manager shall discard the response and 
reissue the command. All other responses with a status of CHECK CONDITION, including those with a sense key 
of NOT READY, shall be returned to the local SMC device server. 

After issuing a command to the remote SMC device server, the bridging manager shall not issue another command 
to the remote SMC device server until the previous command completes or is aborted. 

4.3.5 Caching SMC data and status 

The local SMC device server may preserve some data or status received from the remote SMC device server in a 
cache, in order to respond to certain commands without need for the bridging manager to invoke a command on 
the remote SMC device server (e.g., the local SMC device server may save the standard INQUIRY data from the 
remote SMC device server and return the data to any initiator port that requests it). The local SMC device server 
shall invalidate any data and status previously saved in a cache if the enable bit in the SMC Logical Unit descriptor 
(see 6.2.2.3.3) is set to zero or the cache bit in the SMC Logical Unit descriptor is set to zero. 

Caching of SMC ready state, standard INQUIRY data (see SPC-3), VPD data, mode data, and supported operation 
codes is controlled by the cache bit in the SMC Logical Unit descriptor (see 6.2.2.3.3). When the cache bit is set to 
one, caching is enabled. If caching is enabled, then the automation application client shall send the NOTIFY DATA 
TRANSFER DEVICE command (see 5.2) to the ADC device server when events occur that may change data 
cached by the local SMC device server. When the local SMC device server detects a possible change in the 
cached data, the local SMC device server shall discontinue using the cached data until the cached data has been 
updated. An ADC device server that supports setting the cache bit to one in the SMC Logical Unit descriptor shall 
also support a NOTIFY DATA TRANSFER DEVICE command with a value of one in one or more of the mdc bit, idc 
bit, nrsc bit, and socc bit (see 5.2). 

If caching is disabled, then the ADC device server shall ignore the mdc bit, idc bit, nrsc bit, and socc bit in the 
NOTIFY DATA TRANSFER DEVICE command. As a result, the automation application client is not required to 
send a NOTIFY DATA TRANSFER DEVICE command for purposes of indicating changes in cached data. The 
automation application client may send a NOTIFY DATA TRANSFER DEVICE command to notify the ADC device 
server of events not related to changes in cached data. 

Ready state indicates whether the remote SMC device server is accessible. The remote SMC device server is not 
accessible if it would respond to a command with a CHECK CONDITION status with the sense key set to NOT 
READY. Otherwise, it is accessible. The local SMC device server may monitor the ready state of the remote SMC 
device server via the cache. If the ready state indicates not accessible, then the local SMC device server shall 
terminate commands that require the remote SMC device server to be accessible (see SMC-3) with CHECK 
CONDITION status, with the sense key to NOT READY, and the additional sense code set to the additional sense 
code contained in the cache. 
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4.4 Load and unload states 

4.4.1 Load states 

Table 2 defines the states that may be reported in the VHF data descriptor (see 6.1.2.2) during load operations. 
This information allows automation devices to coordinate loading and unloading of a medium with the DT device, 
and to obtain DT device activity status. 


Table 2 — Load states 


Load state 

Bit in the VHF data descriptor 

INXTN 

RAA 

MPRSNT 

MSTD 

MTHRD 

MOUNTED 

a) DT device initialized, no medium present 

0 

1 

0 

0 

0 

0 

b) Early detection of medium placement by DT device 

0 

1 

1 

0 

0 

0 

c) Acknowledgement of medium control by DT device 

0 

0 

1 

0 

0 

0 

d) Medium seating 

1 

0 

1 

0 

0 

0 

e) Medium seated 

0 

0 

1 

1 

0 

0 

f) Medium threading 

1 

0 

1 

1 

0 

0 

g) Medium threaded 

0 

0 

1 

1 

1 

0 

h) Completing load 

1 

0 

1 

1 

1 

0 

i) Medium mounted 

0 

0 

1 

1 

1 

1 


Load states (a) and (i) shall be supported by the ADC device server. States (b) through (h) (i.e., all other states) 
should be supported to accurately reflect the states used by the DT device. Load states may not be reported in the 
order listed in table 2. 

To indicate an error in any of the listed states, or to report a state not listed, the rrqst bit in the VHF data descriptor 
shall be set to one and the inxtn bit shall be set to zero. 

The DT device shall set the inxtn bit to zero when the DT device requires an external stimulus (e.g., a command or 
medium movement) to attempt to reach another state. The DT device may set the inxtn bit to zero when the DT 
device requires an internal stimulus (e.g., completion of a cleaning operation when using a cleaning cartridge) to 
attempt to reach another state. 

Load state (a) represents an empty DT device, available for loading by the automation device. 

Load state (b) represents initial placement of a medium into the DT device by the automation device. Depending on 
the DT device’s design, medium present may also be detected and reported coincident with load state (b). An 
additional external stimulus is required to leave load state (b) (e.g., medium movement caused by the automation 
device). 

Load state (c) represents detection and acknowledgement by the DT device of medium presence, and that the DT 
device may now assume control of the medium and that the automation device should relinquish control of robotic 
access (e.g., this state may be reflected after medium movement caused by the automation device). An additional 
external stimulus is required to leave load state (c) (e.g., a LOAD UNLOAD command (see SSC-2) from the 
automation device). 
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Load state (d) represents a medium loading under the control of the DT device (e.g., to seat the medium). 

Load state (e) represents a seated medium. An additional external stimulus is required to leave load state (e) (e.g., 
a command from the automation device or a LOAD UNLOAD command to the RMC device server). Load state (e) 
may be used in conjunction with MAM access. 

Load state (f) represents a medium threading under control of the DT device. 

Load state (g) represents a threaded medium. An additional external stimulus is required to leave load state (g) 
(e.g., a command from the automation device). 

Load state (h) represents any additional processing that may be done by the DT device after threading the 
medium, but prior to the load being fully complete (e.g., allow data access). 

Load state (i) represents a mounted medium. 

A medium is mounted in a DT device when the DT device is physically capable of processing operations that 
involve interactions between the read/write element(s) of the DT device and the operational substrate of the 
medium. The interactions between the read/write element(s) of the DT device and the operational substrate of the 
medium may vary depending on the medium type (e.g. altering or detecting the magnetic polarization of the opera¬ 
tional substrate for a magnetically recordable medium or physical abrasion of the read/write element(s) for a 
cleaning medium). A medium in a DT device is not mounted when the medium is seating, threading, positioning to 
its usable area, unthreading, or unseating. During operations involving a cleaning medium, some removable 
medium devices position to a previously unused location on the medium prior to performing the cleaning operation. 
For such technologies the device server should consider the medium as mounted prior to positioning over the 
previously used locations on the cleaning medium. 

An example showing use of a few of the states is given in table 3. 


Table 3 — Load states example 


Load event 

Bit in the VHF data descriptor 

INXTN 

RAA 

MPRSNT 

MSTD 

MTHRD 

MOUNTED 

1) DT device initialized, no medium present 

0 

1 

0 

0 

0 

0 

2) Initial medium placement into DT device 

0 

1 

0 

0 

0 

0 

3) After the automation device pushes a medium 
into DT device, now seating 

1 

0 

1 

0 

0 

0 

4) After seating, medium now threading 

1 

0 

1 

1 

0 

0 

5) Medium threaded, completing load 

1 

0 

1 

1 

1 

0 

6) Medium mounted 

0 

0 

1 

1 

1 

1 


In this example, the DT device is loaded by the automation device first placing a medium into the DT device, then 
pushing the medium far enough into the DT device so that the DT device engages the medium and completes the 
operation in one continuous motion. 

1) the load sequence begins with the DT device initialized, no medium present and robotic access allowed; 

2) the automation device then places the medium into the DT device, which is not yet recognized by the DT 
device; 
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3) after the initial placement, the automation device pushes the medium into the DT device, such that medium 
presence is detected and the DT device assumes control of the medium and seats it; 

4) the DT device continues transitioning through states as it threads the medium; 

5) after threading, the DT device makes final microcode preparations to access the medium; and 

6) the load is complete. 

4.4.2 Unload states 

Table 4 defines the states that may be reported in the VHF data descriptor (see 6.1.2.2) during unload operations. 
This information allows automation devices to coordinate loading and unloading of a medium with the DT device, 
and to obtain DT device activity status. 


Table 4 — Unload states 


Unload state 

Bit in the VHF data descriptor 

INXTN 

RAA 

MPRSNT 

MSTD 

MTHRD 

MOUNTED 

a) Medium mounted 

0 

0 

1 

1 

1 

1 

b) DT device rewinding 

1 

0 

1 

1 

1 

0 

c) Medium unthreaded, still unloading 

1 

0 

1 

1 

0 

0 

d) Medium unseated, unloading or ejecting 

1 

0 

1 

0 

0 

0 

e) DT device unloaded (hold point), seated 

0 

0 

1 

1 

0 

0 

f) DT device unloaded (hold point), unseated 

0 

0 

1 

0 

0 

0 

g) Medium ejected, presence detected 

0 

1 

1 

0 

0 

0 

h) Medium ejected, presence not detected 

0 

1 

0 

0 

0 

0 


Unload states (a) and (h) shall be supported by the ADC device server. States (b) through (g) (i.e., all other states) 
should be reported to accurately represent the states used by the DT device. Unload states may not be reported in 
the order listed in table 4. 

To indicate an error in any of the listed states, or to report a state not listed, the rrqst bit in the VHF data descriptor 
shall be set to one and the inxtn bit shall be set to zero. 

Unload state (a) represents the initial DT device state prior to receiving a request to unload. 

Unload state (b) represents the initial DT device state after receiving a request to unload. 

Unload state (c) represents the DT device state during the unload operation after the medium has been 
unthreaded. 

Unload state (d) represents the DT device state during the unload operation after the medium has been unseated 
and the DT device state during the eject operation. 

Unload state (e) represents the DT device state after unloading to the hold point, where the medium is still seated. 
An external stimulus (e.g., a request to eject or load) is needed to leave unload state (e). 

Unload state (f) represents the DT device state after unloading to the hold point, where the medium is also 
unseated. An external stimulus (e.g., a request to eject or load) is needed to leave unload state (f). 


Working draft Automation/Drive Interface Commands - 2 (ADC - 2) 


18 




T10/1741 -D Revision8 


10 July 2007 


Unload state (g) represents the DT device state after the medium is unloaded, ejected, and the DT device is still 
able to report medium present until the medium is completely removed. 

Unload state (h) represents the DT device state after the medium is ejected and the presence of the medium is not 
detected (i.e., the DT device either does not support detection of medium presence at this state or the medium has 
been removed). 

As an example, an unload to the hold point sequence may use states (a), (b), (c) and (e), or alternatively (a), (b), 
(c), (d), and (f). An unload to eject sequence may use states (a), (b), (c), (d), and (h). 


4.5 Sense data masking 

In the process of loading a medium into a DT device, it may be necessary to retry the load operation in order to 
overcome transient failures. Retrying the load operation may require removing and re-inserting the medium into the 
DT device. If an application client is testing the status of the RMC device server, then the application client may see 
an initial failure even though the loading eventually succeeds and the MOVE MEDIUM command to the SMC 
device returns GOOD status. 

If the optional sense data masking feature is implemented, then the RMC device server's true status is not reported 
to the application client during automation device-initiated loads. Instead, the automation device may retry the load 
operation while the RMC device server reports that the load operation is still in progress to application clients. 

If implemented, then the DT device shall enable sense data masking when the DT device begins loading a 
medium. The DT device shall disable sense data masking after any of the following occur: 

a) loading succeeds; 

b) loading fails and for a time equal to sense masking timeout value (SM_TOV) the automation device issues 
no medium access commands and does not remove and re-insert the medium; 

c) the ADC device server receives a NOTIFY DATA TRANSFER DEVICE command with the ldfail bit set to 
one (see 5.2); or 

d) the medium is removed and SM TOV expires before the medium is re-inserted. 

While sense data masking is enabled, then the RMC device server shall report status and sense data consistent 
with a normal loading operation. 

During the SM_TOV period, if either the automation application client issues a medium access command or the 
automation device removes and re-inserts the medium, then the DT device shall not disable sense data masking. 
The SM_TOV timer shall be restarted when either the medium is re-inserted or the command is received. 

After disabling sense data masking, the RMC device server shall report status and sense data indicating the load is 
in progress, and not report any failure that is encountered. 

The value of SM_TOV is vendor-specific. 


4.6 TapeAlert application client interface 

The ADC device server supports a modified version of TapeAlert specified in SSC-2. As supported by the ADC 
device server, the TapeAlert flags represent states, and the state flags are not set to zero upon retrieval of the 
TapeAlert Response log page (see 6.1.3). Instead, the state flags are set to zero upon a change of the condition 
involved with the state (see table 5). 
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To facilitate accurate reporting of the conditions encountered by the DT device and allow the automation device to 
manage the information directly, the ADC device server does not maintain unique TapeAlert information for each 
l_T nexus, and the state flags are not affected by an l_T nexus loss condition (see SAM-3). 

The application client is responsible for determining which flags have changed state upon subsequent retrieval of 
the TapeAlert Response log page, requiring the application client to maintain at least one previously retrieved 
TapeAlert Response log page in order to detect differences. The application client may maintain a state change 
history. 

In conjunction with the VHF data descriptor (see 6.1.2.2), the TapeAlert state flags are a primary source of infor¬ 
mation about the DT device, and should be used to obtain DT device status information. Application clients may 
retrieve TapeAlert state flags at any time. Application clients should retrieve TapeAlert state flags after receiving 
from the DT device a VHF data descriptor with the TapeAlert Flags Changed (tafc) bit to one. 

The ADC device server shall maintain the TapeAlert state flags independently of the TapeAlert flags maintained by 
the RMC device server. Retrieving the state flags from the ADC device server shall not set the state flags 
maintained by the ADC device server to zero and shall not set the TapeAlert flags maintained by the RMC device 
server to zero. Retrieving TapeAlert flags from the RMC device server shall not set the state flags maintained by 
the ADC device server to zero. 

The TapeAlert state flags shall be set to zero upon a logical unit reset to either the RMC or ADC device servers. 
The state flags shall be reported as new states following power on as conditions warrant. In addition to power on, 
other conditions and events that cause TapeAlert state flags to be set to zero are described in table 5. 


Table 5 — Additional conditions that cause TapeAlert state flags to be set to zero (part 1 of 3) 


Flag 

Name 

Additional clearing condition 

Olh 

Read warning 

Start of next medium load 

02h 

Write warning 

Start of next medium load 

03h 

Hard error 

Start of next medium load 

04 h 

Media 

Start of next medium load 

05h 

Read failure 

Start of next medium load 

06h 

Write failure 

Start of next medium load 

07h 

Media life 

Start of next medium load 

08h 

Not data grade 

Start of next medium load 

09h 

Write protect 

Start of next medium load or removal of write protect 

OAh 

No removal 

After medium removal allowed 

OBh 

Cleaning media 

Start of next medium load 

OCh 

Unsupported format 

Start of next medium load or format change 

ODh 

Recoverable mechanical cartridge failure 

Start of next medium load 

OEh 

Unrecoverable mechanical cartridge failure 

After service resolution 

OFh 

Memory chip in cartridge failure 

Start of next medium load 

lOh 

Forced eject 

Start of next medium load 
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Table 5 — Additional conditions that cause TapeAlert state flags to be set to zero (part 2 of 3) 


Flag 

Name 

Additional clearing condition 

11 h 

Read only format 

Start of next medium load or format change 

12h 

Tape directory corrupted on load 

Start of next medium load 

13h 

Nearing media life 

Start of next medium load 

14h 

Cleaning required 

After successful cleaning or cause resolved 

15h 

Cleaning requested 

After successful cleaning 

16h 

Expired cleaning media 

Start of next medium load 

17h 

Invalid cleaning tape 

Start of next medium load 

18h 

Retension requested 

After successful retension 

19h 

Dual-port interface error 

After interface returns to operation 

1Ah 

Cooling fan failure 

After service resolution 

IBh 

Power supply failure 

After service resolution 

ICh 

Power consumption 

After power consumption returns to within specification 

IDh 

Drive maintenance 

After service resolution 

1Eh 

Hardware A 

After service resolution 

IFh 

Hardware B 

After service resolution 

20h 

Interface 

After interface returns to operation 

21h 

Eject media 

Start of next medium load 

22h 

Microcode update fail 

Start of next microcode update 

23h 

Drive humidity 

After humidity returns to within specification 

24 h 

Drive temperature 

After temperature returns to within specification 

25h 

Drive voltage 

After voltage returns to within specification 

26h 

Predictive failure 

After service resolution 

27h 

Diagnostics required 

After service resolution 

28h- 2Eh 

Obsolete 


2Fh- 31 h 

Reserved 


32h 

Lost statistics 

Start of next medium load 

33h 

Tape directory invalid at unload 

Start of next medium load 

34 h 

Tape system area write failure 

Start of next medium load 

35h 

Tape system area read failure 

Start of next medium load 

36h 

No start of data 

Start of next medium load 
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Table 5 — Additional conditions that cause TapeAlert state flags to be set to zero (part 3 of 3) 


Flag 

Name 

Additional clearing condition 

37h 

Loading failure 

Start of next medium load 

38h 

Unrecoverable unload failure 

After service resolution 

39h 

Automation interface failure 

After service resolution 

3Ah 

Microcode failure 

After service resolution 

3Bh 

WORM medium - Integrity Check Failed 

Start of next medium load 

3Ch 

WORM medium - Overwrite Attempted 

Start of next medium load 

3Dh-40h 

Reserved 



Many of the state flags are set to zero at the start of the next medium load (see table 5), which is defined to be the 
DT device entering the next load state upon transition from load state (a) (see table 2). The next load state entered 
varies by DT device. If a load sequence is initiated from an unload hold point (i.e., unload state (e) or (f) in table 4), 
start of next medium load is defined to be the DT device entering the next load state upon transition from load 
states (c) or (e) (see table 4). 

Other state flags are set to zero following service resolution (see table 5). Service resolution is beyond the scope of 
this standard. 


4.7 Medium Auxiliary Memory attributes 

ADC device servers shall not modify attributes of type Host. To change these attributes, the automation application 
client shall issue the WRITE ATTRIBUTE command (see SPC-3) to the RMC device server. 

ADC device servers may modify the VOLUME IDENTIFIER attribute of type Device. 


4.8 DT device primary ports 

4.8.1 DT device primary port index 

The DT device shall assign a primary port index value that uniquely identifies the DT device primary port relative to 
other DT device primary ports in the DT device, independent of DT device primary port type. Once assigned, the 
primary port index value for a DT device primary port shall not be changed as long as the DT device primary port 
remains on the DT device. A value of OOh is reserved. The primary port index value assigned to a DT device 
primary port may or may not be the same as the relative target port identifier (see SPC-3) assigned to the port. 

4.8.2 Enabling and disabling DT device primary ports 

A DT device shall allow the DT device primary port(s) to be disabled and enabled via MODE SELECT commands 
(see SPC-3) to the ADC device server that modify the DT Device Primary Port mode page (see 6.2.2.2). 

The behavior of a DT device primary port if the port is disabled is protocol dependent (see 6.2.2.2). 
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The disabling of a DT device primary port shall be treated as an l_T nexus loss event (see SAM-3) for any existing 
l_T nexus associated with the disabled DT device primary port. If the command disabling a DT device primary port 
is received through the DT device primary port being disabled, then the ADC device server shall return status for 
the MODE SELECT command before disabling the DT device primary port. 


4.9 Sequential mode operation 

Some automation devices support a sequential mode of operation. When an automation device is configured in 
sequential mode, there is no SMC device server accessible in the SCSI domain. In sequential mode the 
automation device implicitly replaces a medium in the DT device with the next sequential medium in the 
automation device. A typical sequence of operations is: 

1) the RMC device server receives and processes a command that requests that the medium be unloaded; 

2) the automation device detects that an unload of the medium has occurred; 

3) the automation device removes the current medium from the DT device and returns the medium to its 
storage element; 

4) the automation device moves the next medium from a storage element to the DT device; and 

5) the RMC device server becomes ready for access. 

The automation device may use the hiu bit in the VHF data descriptor (see 6.1.2.2) to aid in the detection of an 
unloaded medium in step 2 of the sequence of operation shown in this subclause. 
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5 Commands for automation/drive interface devices 

5.1 Summary of commands for automation/drive interface devices 

The command set for automation/drive interface devices is shown in table 6. Commands specified as mandatory in 
table 6 shall be implemented by automation/drive interface devices. 


Table 6 — Command set for automation/drive interface (part 1 of 3) 


Command name 

Operation 

code 

Type 

Reference 

ACCESS CONTROL IN 

86h 

0 

SPC-3 

ACCESS CONTROL OUT 

87h 

0 

SPC-3 

CHANGE ALIASES 

A4h/0Bh a 

0 

SPC-3 

EXTENDED COPY 

83h 

0 

SPC-3 

INQUIRY 

12h 

M 

SPC-3 

LOAD UNLOAD 

IBh 

M 

SSC-2 

LOG SELECT 

4Ch 

0 

SPC-3 

LOG SENSE 

4Dh 

M 

SPC-3 

MODE SELECT(6) 

15h 

0 

SPC-3 

MODE SELECT(IO) 

55h 

M 

SPC-3 

MODE SENSE(6) 

1Ah 

0 

SPC-3 

MODE SENSE(IO) 

5Ah 

M 

SPC-3 

NOTIFY DATA TRANSFER DEVICE 

9Fh/1Fh a 

M 

5.2 

READ ATTRIBUTE 

8Ch 

M 

SPC-3 

READ BUFFER 

3Ch 

0 

SPC-3 

READ MEDIA SERIAL NUMBER 

ABh/Olh a 

0 

SPC-3 

Type Key: M = mandatory 

0 = optional 

a This command is defined by a combination of operation code and service action. The operation code value is 
shown preceding the slash and the service action value is shown after the slash. 
b This command is subject to the readiness of the removable medium (i.e., the logical unit is able to process 
medium-access commands without returning CHECK CONDITION status). Other commands may be subject 
to readiness of the removable medium due to vendor-specific features. 
c This command is subject to the readiness of the removable medium when the media bit is set to one. 
d Only mandatory for devices that include an SSC-3 compliant device server. 
e Only self test shall be mandatory. 
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Table 6 — Command set for automation/drive interface (part 2 of 3) 


Command name 

Operation 

code 

Type 

Reference 

RECEIVE COPY RESULTS 

84 h 

0 

SPC-3 

RECEIVE DIAGNOSTIC RESULTS 

ICh 

0 

SPC-3 

REPORT ALIASES 

A3h/0Bh a 

0 

SPC-3 

REPORT DENSITY SUPPORT c 

44 h 

M d 

SSC-3 

REPORT DEVICE IDENTIFIER 

A3h/05h a 

0 

SPC-3 

REPORT LUNS 

AOh 

M 

SPC-3 

REPORT PRIORITY 

A3h/0Eh a 

0 

SPC-3 

REPORT SUPPORTED OPERATION CODES 

A3h/0Ch a 

M 

SPC-3 

REPORT SUPPORTED TASK MANAGEMENT FUNCTIONS 

A3h/0Dh a 

0 

SPC-3 

REPORT TARGET PORT GROUPS 

A3h/0Ah a 

0 

SPC-3 

REPORT TIMESTAMP 

A3h/0Fh a 

0 

SPC-3 

REQUEST SENSE 

03h 

M 

SPC-3 

SECURITY PROTOCOL IN 

A2h 

0 

SPC-4 

SECURITY PROTOCOL OUT 

B5h 

0 

SPC-4 

SEND DIAGNOSTIC 

IDh 

M e 

SPC-3 

SET DEVICE IDENTIFIER 

A4h/06h a 

0 

SPC-3 

SET MEDIUM ATTRIBUTE 

A9h/1Fh a 

0 

5.3 

SET PRIORITY 

A4h/0Eh a 

0 

SPC-3 

SET TARGET PORT GROUPS 

A4h/0Ah a 

0 

SPC-3 

Type Key: M = mandatory 

0 = optional 

a This command is defined by a combination of operation code and service action. The operation code value is 
shown preceding the slash and the service action value is shown after the slash. 
b This command is subject to the readiness of the removable medium (i.e., the logical unit is able to process 
medium-access commands without returning CHECK CONDITION status). Other commands may be subject 
to readiness of the removable medium due to vendor-specific features. 
c This command is subject to the readiness of the removable medium when the media bit is set to one. 
d Only mandatory for devices that include an SSC-3 compliant device server. 
e Only self test shall be mandatory. 
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Table 6 — Command set for automation/drive interface (part 3 of 3) 


Command name 

Operation 

code 

Type 

Reference 

SET TIMESTAMP 

A4h/0Fh a 

0 

SPC-3 

TEST UNIT READY b 

OOh 

M 

SPC-3 

WRITE ATTRIBUTE 

8Dh 

0 

SPC-3 

WRITE BUFFER 

3Bh 

0 

SPC-3 

Type Key: M = mandatory 

0 = optional 

a This command is defined by a combination of operation code and service action. The operation code value is 
shown preceding the slash and the service action value is shown after the slash. 
b This command is subject to the readiness of the removable medium (i.e., the logical unit is able to process 
medium-access commands without returning CHECK CONDITION status). Other commands may be subject 
to readiness of the removable medium due to vendor-specific features. 
c This command is subject to the readiness of the removable medium when the media bit is set to one. 
d Only mandatory for devices that include an SSC-3 compliant device server. 
e Only self test shall be mandatory. 
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5.2 NOTIFY DATA TRANSFER DEVICE command 

The NOTIFY DATA TRANSFER DEVICE command (see table 7) notifies the ADC device server of specific events. 
The NOTIFY DATA TRANSFER DEVICE command does not represent the complete current state of the 
automation device and is not intended to be sent upon every change in the automation device's state. 

If a NOTIFY DATA TRANSFER DEVICE command is received from an I T nexus with a pending unit attention 
condition (i.e., before the ADC device server reports CHECK CONDITION status), then the ADC device server 
shall process the NOTIFY DATA TRANSFER DEVICE command and shall not clear the unit attention condition. 

The automation application client shall send the NOTIFY DATA TRANSFER DEVICE command when any of the 
events that the NOTIFY DATA TRANSFER DEVICE command reports have occurred. Multiple events may be 
reported in the same NOTIFY DATA TRANSFER DEVICE command. The command shall report only those events 
that have not been previously reported. 


Table 7 — NOTIFY DATA TRANSFER DEVICE command 


Bit 

Byte 

7 6 5 4 3 2 1 

0 

0 

OPERATION CODE (9Fh) 

1 

Reserved service action (IFh) 

2 

Reserved 

LDFAIL 

3 

Reserved socc bua nrsc idc 

MDC 

4 

asc 

5 

ASCQ 

6 


14 

Reserved 

15 

CONTROL 


A load failed (ldfail) bit set to one specifies the automation device has detected that the rrqst bit in the VHF data 
descriptor (see 6.1.2.2) is set to one while the DT device is attempting to load a medium, and the automation 
device has completed all recovery attempts. A ldfail bit set to zero specifies that a load failure has not been 
detected. 

The mdc bit, idc bit, nrsc bit, and socc bit are used to specify that cached SMC data may require refreshing (see 
4.3.5). 

A supported operation codes changed (socc) bit set to one specifies that the list of operation codes supported by 
the remote SMC device server has changed. Upon successful completion of a NOTIFY DATA TRANSFER 
command with the socc bit set to one, the use of any cached operation code list shall be discontinued until the 
cached list has been refreshed. A socc bit set to zero specifies that the list of operation codes supported by the 
remote SMC device server has not changed. If the cache bit in the SMC Logical Unit descriptor is set to one, then 
the ADC device server shall support the socc bit set to one, but shall ignore the bit if the operation codes 
supported by the remote SMC device server are not cached. 

A broadcast unit attention (bua) bit set to one specifies that the asc field and ascq field contain the additional 
sense data that shall be used by the local SMC device server to establish a unit attention condition for all I T 
nexuses accessible via the DT device primary ports. If none of the known l_T nexuses are able to have a unit 
attention condition established by the device server due to insufficient resources, then the device server shall 
terminate the NOTIFY DATA TRANSFER DEVICE command with a CHECK CONDITION status and set the sense 
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key to ILLEGAL REQUEST and the additional sense code to INSUFFICIENT RESOURCES. If the additional 
sense data in the asc field and ascq field is set to NOT READY TO READY CHANGE, MEDIUM MAY HAVE 
CHANGED, then the remote SMC device server ready state has transitioned to accessible (see 4.3.5). A bua bit 
set to zero specifies that the asc field and ascq field contents shall not be used by the local SMC device server to 
establish a unit attention condition for any l_T nexuses accessible via the DT device primary ports. 

NOTE 2 The return of GOOD status for a NOTIFY DATA TRANSFER DEVICE command with the BUA bit set to 

one does not guarantee delivery of the unit attention condition to every I T nexus known to the DT device. 

A not ready state changed (nrsc) bit set to one indicates that the remote SMC device server ready state has transi¬ 
tioned to indicate not accessible (see 4.3.5). A nrsc bit set to one may also indicate that the remote SMC device 
server ready state already indicated not accessible state and the sense data changed. When the nrsc bit is set to 
one, the asc field and ascq field contain additional sense data appropriate to the condition. Upon successful 
completion of a NOTIFY DATA TRANSFER command with the nrsc bit set to one, the cached ready state and 
additional sense data shall be updated. A nrsc bit set to zero indicates that the remote SMC device server ready 
state has not transitioned to indicate not accessible state, nor has the additional sense data changed if the remote 
SMC device server ready state already indicated not accessible. If the cache bit in the SMC Logical Unit descriptor 
is set to one, then the ADC device server shall support the nrsc bit set to one, but shall ignore the nrsc bit if the 
ready state is not cached. 

If the nrsc bit and the bua bit are both set to one, or if both bits are set to zero and either the asc field or the ascq 
field is not set to zero, then the command shall be terminated with a CHECK CONDITION status. The sense key 
shall be set to ILLEGAL REQUEST and the additional sense code shall be set to INVALID FIELD IN CDB. 

An INQUIRY data changed (idc) bit set to one specifies that the contents of the standard INQUIRY data or any 
VPD page data reported by the remote SMC device server have changed. Upon successful completion of a 
NOTIFY DATA TRANSFER command with the idc bit set to one, the use of any cached INQUIRY data or VPD 
pages shall be discontinued until the cached data have been refreshed. An idc bit set to zero specifies that the 
contents have not changed. If the cache bit in the SMC Logical Unit descriptor is set to one, then the ADC device 
server shall support the idc bit set to one, but shall ignore the bit if INQUIRY data is not cached. 

A mode data changed (mdc) bit set to one specifies that the contents of a mode page or mode parameter header 
reported by the remote SMC device server have changed. Upon successful completion of a NOTIFY DATA 
TRANSFER command with the mdc bit set to one, the use of any cached mode data by the local SMC device 
server (see 4.3.2) shall be discontinued until the cached mode data has been refreshed. A mdc bit set to zero 
specifies that the contents have not changed. If the cache bit in the SMC Logical Unit descriptor is set to one (see 
6.2.2.3.3), then the ADC device server shall support the mdc bit set to one, but shall ignore the bit if mode data is 
not cached. 
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5.3 SET MEDIUM ATTRIBUTE command 

5.3.1 SET MEDIUM ATTRIBUTE command introduction 

The SET MEDIUM ATTRIBUTE command (see table 8) is used to pass attributes of the medium to the ADC device 
server. The device server may use any attributes set by this command to: 

a) add the attribute to log entries the DT device creates; 

b) add the attribute to the device type specific area in the MAM (see SPC-3); 

c) report the attribute to application clients in response to commands or other means beyond the scope of this 
standard; or 

d) other uses beyond the scope of this standard. 


Table 8 — SET MEDIUM ATTRIBUTE command 


Bit 

Byte 

7 6 5 4 3 2 1 0 

0 

OPERATION CODE (A9h) 

1 

Reserved service action (IFh) 

2 


5 

Reserved 

6 

(MSB) 

9 

PARAMETER LIST LENGTH 

(LSB) 

10 

Reserved 

11 

CONTROL 


See SPC-3 for the description of the parameter list length field. 

The device server shall retain the attributes sent with a SET MEDIUM ATTRIBUTE command when no medium is 
present in the device until: 

a) a SET MEDIUM ATTRIBUTE command is processed that changes the attribute; or 

b) a logical unit reset condition occurs. 

Attributes established when no medium is present shall be applied to the next medium loaded. 

All medium attributes set by the SET MEDIUM ATTRIBUTE command shall be cleared by the device server when 
the medium is removed from the device. 
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5.3.2 SET MEDIUM ATTRIBUTE parameter list format 

The parameter list shall have the format shown in table 9. Medium attributes should be listed in order ascending 
numerical order based on the attribute identifier field (see 5.3.3). 


Table 9 — SET MEDIUM ATTRIBUTE parameter list format 


Bit 

Byte 

7 

6 

5 

4 

3 

2 

1 

0 

0 

(MSB) 

parameter data length (n-3) 


3 


(LSB) 


Medium attribute list 

4 


Medium attribute (first) (see 5.3.3) 









Medium attribute (last) (see 5.3.3) 


n 




The parameter data length field should contain the number of bytes of attribute data. 

The format of the medium attributes is described in 5.3.3. 

No medium attributes shall be changed and the SET MEDIUM ATTRIBUTE command shall be terminated with 
CHECK CONDITION status with the sense key set to ILLEGAL REQUEST and the additional sense code set to 
INVALID FIELD IN PARAMETER LIST, if the parameter data contains any of the following: 

a) a medium attribute with an attribute length that exceeds the value shown in table 11; 

b) a medium attribute with an unsupported or reserved format field (see 5.3.3) value; 

c) a medium attribute with unsupported attribute value field (see 5.3.3) contents and a non-zero attribute 
length field value; or 

d) a medium attribute with a value in the format field that does not match the value shown table 11. 

If the SET MEDIUM ATTRIBUTE command parameter data contains a medium attribute with an attribute length 
field set to zero, then one of the following actions shall occur: 

a) If the medium attribute is supported, the medium attribute’s value shall be cleared; or 

b) If the medium attribute is not supported, the medium attribute shall be ignored and this shall not be 
considered an error. 
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5.3.3 SET MEDIUM ATTRIBUTE attribute format 

Each medium attribute shall be communicated between the application client and device server in the format 
shown in table 10. 


Table 10 — SET MEDIUM ATTRIBUTE attribute format 


Bit 

Byte 

7 

6 

5 

4 

3 

2 

1 

0 

0 

(MSB) 

ATTRIBUTE IDENTIFIER 


1 


(LSB) 

2 

Reserved format 

3 

Reserved 

4 

(MSB) 

ATTRIBUTE LENGTH (n-5) 


5 


(LSB) 

6 


ATTRIBUTE VALUE 


n 




The attribute identifier field (see table 11) specifies the medium attribute to be set. 


Table 11 — attribute identifier field 


Code 

Description 

Format 

Maximum 

length 

(bytes) 

OOOOh 

Volume identifier (see SMC-3) 

ASCII 

32 

0001h-FF7Fh 

Reserved 



FF80h-FFFFh 

Vendor specific 




The format field (see table 12) specifies the format of the data in the attribute value field. 

Table 12 — format field 


Code 

Name 

Description 

00b 

BINARY 

The attribute value field contains binary data. 

01b 

ASCII 

The attribute value field contains left-aligned ASCII data. 

10b-11b 


Reserved 


The attribute length field specifies the length in bytes of the attribute value field. 
The attribute value field contains the intended value of the medium attribute. 
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6 Parameters for automation/drive interface devices 

6.1 Log parameters 

6.1.1 Log parameters overview 

This subclause defines the log pages and log parameters for ADC device servers. 
The log page codes for ADC device servers are defined in table 13. 


Table 13 — Log page codes 


Page code 

Description 

Support 

requirement 

Reference 

OOh 

Supported Log Pages page 

Mandatory 

SPC-3 

Olh 

Buffer Overrun/Underrun log page 

Optional 

SPC-3 

02h 

Write Error Counter log page 

Optional 

SPC-3 

03h 

Read Error Counter log page 

Optional 

SPC-3 

04 h 

Read Reverse Error Counter log page 

Optional 

SPC-3 

05h 

Verify Error Counter log page 

Optional 

SPC-3 

06h 

Non-Medium Error log page 

Optional 

SPC-3 

07h 

Last n Error Events log page 

Optional 

SPC-3 

08h 

Format Status log page 

Optional 

SPC-3 

09h - OAh 

Reserved 



OBh 

Last n Deferred Error Events log page 

Optional 

SPC-3 

OCh 

Sequential-Access Device log page 

Optional 

SSC-2 

ODh 

Temperature log page 

Optional 

SPC-3 

OEh 

Start-Stop Cycle Counter log page 

Optional 

SPC-3 

OFh 

Application Client log page 

Optional 

SPC-3 

lOh 

Self-Test Results log page 

Optional 

SPC-3 

11 h 

DT Device Status log page 

Mandatory 

6.1.2 

12h 

TapeAlert Response log page 

Mandatory 

6.1.3 

13h 

Requested Recovery log page 

Mandatory 

6.1.4 

14h 

Device Statistics log page 

Optional 

SSC-3 

15h 

Service Buffers Information log page 

Optional 

6.1.5 

16h - 17h 

Reserved 



18h 

Protocol Specific Port log page 

Optional 

SPC-3 

19h-2Eh 

Reserved 



2Fh 

Informational Exceptions log page 

Optional 

SPC-3 

30h-3Eh 

Vendor-specific log pages 



3Fh 

Reserved 
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Changes to log parameters caused by either LOG SELECT commands or other DT device operation of an RMC 
device server shall not be reflected by changes in the corresponding parameters reported by the ADC device 
server (i.e., log parameters of ADC and RMC device servers in the same DT device are independent). Changes in 
log parameters caused by either LOG SELECT commands or other DT device operation of an ADC device server 
shall not be reflected by changes in the corresponding parameters reported by the RMC device server. 


6.1.2 DT Device Status log page 

6.1.2.1 DT Device Status log page overview 

The DT Device Status log page (see table 14) defines log information pertaining to the DT device and DT device 
primary ports. 


Table 14 — DT Device Status log page 


Bit 

Byte 

7 

6 

5 

4 

3 

2 

1 

0 

0 

Reserved 

PAGE CODE (11 h) 

1 

Reserved 

2 

(MSB) 

PAGE LENGTH (n-3) 


3 


(LSB) 

4 


DT Device Status log parameters 


n 




See SPC-3 for a description of the page code field and page length field. 
Table 15 defines the DT Device Status log page parameter codes. 


Table 15 — DT Device Status log page parameter codes 


Parameter code 

Description 

Reference 

OOOOh 

Very high frequency data 

6.1.2.2 

0001 h 

Very high frequency polling delay 

6.1.2.3 

0002h - OOFFh 

Reserved 


lOOh 

Obsolete 


0101 h-OlFFh 

DT device primary port status 

6.1.2.4 

0200h - 7FFFh 

Reserved 


8000h - FFFFh 

Vendor-specific 



6.1.2.2 Very high frequency data log parameter 

The very high frequency data log parameter format is shown in table 16. 
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Table 16 — Very high frequency data log parameter format 


Bit 

Byte 

7 

6 

5 

4 

3 

2 

1 

0 

0 

(MSB) 

PARAMETER CODE (OOOOh) 


1 


(LSB) 

2 

DU (0) DS (1) TSD (0) ETC (0) TMC (00) LBIN (1) LP(1) 

3 

PARAMETER LENGTH (04h) 

4 


VHF data descriptor 


7 




The parameter code field shall be set to OOOOh to indicate the very high frequency data log parameter. 

See SPC-3 for descriptions of the du bit, ds bit, tsd bit, etc bit, tmc field, lbin bit, and lp bit. These bits and fields 
shall be set to the values shown in table 16. 

The parameter length field shall be set to 04h. 

The VHF data descriptor is defined in table 17. 


Table 17 — VHF data descriptor 


Bit 

Byte 

7 

6 

5 

4 

3 

2 

1 

0 

0 

PAMR 

HIU 

MACC 

CMPR 

WRTP 

CRQST 

CRQRD 

DINIT 

1 

INXTN 

Rsvd 

RAA 

MPRSNT 

Rsvd 

MSTD 

MTHRD 

MOUNTED 

2 

DT DEVICE ACTIVITY 

3 

VS 


Reserved 


RRQST 

INTFC 

TAFC 


The prevent/allow medium removal (pamr) bit shall be set to one when removal of the medium in the DT device is 
prevented as the result of the RMC device server processing a PREVENT ALLOW MEDIUM REMOVAL command 
(see SPC-3 or the relevant command standard). The pamr bit shall be set to zero when removal of the medium in 
the DT device is allowed as defined by the PREVENT ALLOW MEDIUM REMOVAL command. 

The host initiated unload (hiu) bit shall be set to one when the DT device reaches any one of the unload states (e) 
- (h) (see table 4) due to the RMC device server receiving a LOAD UNLOAD command (see SSC-2) with the load 
bit set to zero. The hiu bit shall be set to zero when the DT device transitions to any state in table 2 or table 4 other 
than unload states (e) - (h) in table 4. The hiu bit may be set to zero following a logical unit reset of the RMC or 
ADC device servers. 

NOTE 3 The hiu bit may facilitate sequential mode operation (see 4.9). 

A medium auxiliary memory accessible (macc) bit set to one indicates that the medium is located at a position 
where the MAM is accessible. A macc bit set to zero indicates that the MAM is not accessible. If the macc bit is set 
to one, then the ADC device server shall also support commands to access the MAM. If the macc bit is supported, 
then the macc bit should only be set to one if the mprsnt bit is set to one. The macc bit is only applicable for DT 
devices and media that support MAM. 
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A compress (cmpr) bit set to one indicates that the DT device currently has data compression enabled. A cmpr bit 
set to zero indicates that compression is not enabled. 

A write protect (wrtp) bit set to one indicates that any current medium is physically write protected. A wrtp bit set 
to zero indicates that any current medium is not physically write protected. The wrtp bit is only valid if the mprsnt 
bit is set to one. The wrtp bit should be set to zero if the mprsnt bit is set to zero. 

NOTE 4 Physically write protected refers to any mechanism used within the medium shell itself to write protect the 
medium (e.g., sliding windows or tabs) and not logical states of write protection caused by commands to the DT 
device. 

A cleaning requested (crqst) bit set to one indicates that the DT device has requested a head cleaning. A crqst 
bit set to zero indicates that no cleaning is requested. 

A cleaning required (crqrd) bit set to one indicates that a head cleaning operation is required before a data 
medium is able to reach load state (i) (see 4.4.1), and that normal operation may not be possible if the head 
cleaning operation is not performed. A crqrd bit set to zero indicates that urgent cleaning is not required. It shall 
not be considered an error for the crqrd bit and the crqst bit to both be set to one. 

A DT device initialized (dinit) bit set to one indicates that the DT device is able to return valid very high frequency 
data. A dinit bit set to zero indicates DT device initialization is required or incomplete and the values of other bits in 
the very high frequency data log parameter are indeterminate. 

NOTE 5 In addition to reliance on indication of initialization completion, reliance on returned values should also 
take into consideration conditions indicated by changes in Tape Alert flag status, and process those first as needed. 

The in transition (inxtn) bit governs all of the other bits in byte 1 to indicate the stability of the values returned and 
whether state transitions are taking place. An inxtn bit set to one indicates that the state currently reflected by all of 
the other bits in byte 1 is in transition, because the DT device is transitioning to another state. An inxtn bit set to 
zero indicates that the DT device is in the state reflected by all of the other bits in byte 1 and is making no attempt 
to leave this state. When the recovery requested (rrqst) bit is set to one, the inxtn bit shall be set to zero. 

A robotic access allowed (raa) bit set to one indicates that the automation device may move a medium to or from 
the DT device. A raa bit set to zero indicates that the automation device should not move a medium to or from the 
DT device. The DT device should indicate that access is allowed by the robotics if a medium may be successfully 
inserted into or removed from the DT device. 

NOTE 6 The raa bit is not intended to reflect the value of any PREVENT ALLOW MEDIUM REMOVAL command 
settings (see SPC-3), nor the ability of the automation device to issue commands to the DT device. 

A medium present (mprsnt) bit set to one indicates that the DT device detects the presence of a medium. A 
mprsnt bit set to zero indicates that the DT device does not detect a medium present. 

A medium seated (mstd) bit set to one indicates that the medium is mechanically seated within the loading 
mechanism (i.e., the physical loading process has completed). A mstd bit set to zero indicates that the medium is 
not seated, and that further mechanical motion remains in order to complete the loading process, exclusive of tape 
threading. 

A medium threaded (mthrd) bit set to one indicates that the medium has been threaded by the DT device, such 
that tape motion operations are possible. A mthrd bit set to zero indicates that the medium has not been threaded. 

NOTE 7 The value of the mthrd bit may or may not correspond to the DT device responding with GOOD status to 
a TEST UNIT READY command (see SPC-3), as additional processing may be required by the DT device after 
threading before the logical unit becomes ready. 
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A mounted bit set to one indicates that the DT device is in load state (i) (see 4.4.1). The mounted bit set to one 
may correspond to the RMC device server being able to respond to a TEST UNIT READY command with GOOD 
status, however when a cleaning or microcode image medium is loaded the RMC device server may respond to a 
TEST UNIT READY command with a CHECK CONDITON status with the sense key set to NOT READY. A 
mounted bit set to zero indicates that the DT device is not in load state (i). 

The dt device activity field is used to describe the current activity of the DT device (see table 18). 

Table 18 — dt device activity field 


Code 

Description 

OOh 

No DT device activity 

Olh 

Cleaning operation in progress 

02h 

Medium is being loaded 

03h 

Medium is being unloaded 

04 h 

Other medium activity 

05h 

Reading from medium 

06h 

Writing to medium 

07h 

Locating medium 

08h 

Rewinding medium 

09h 

Erasing medium 

OAh 

Formatting medium 

OBh 

Calibrating medium 

OCh 

Other DT device activity 

ODh 

Microcode update in progress 

OEh 

Reading encrypted from medium 

OFh 

Writing encrypted to medium 

10h-7Fh 

Reserved 

80h-FFh 

Vendor-specific DT device activity 


The recovery requested (rrqst) bit shall be set to one to indicate that the DT device has detected an error and that 
one or more requested recovery procedures are available via the Requested Recovery log page (see 6.1.4). A 
rrqst bit set to zero indicates that no recovery procedure is requested. The rrqst bit shall remain set to one as 
long as a recovery procedure is available. When the rrqst bit is set to one, the inxtn bit shall be set to zero. 

NOTE 8 The Requested Recovery log page may indicate that a recovery procedure is not requested or not defined. 

An interface changed (intfc) bit set to one indicates that one or more fields in the DT device primary port status log 
parameters (see 6.1.2.4) have changed since the last retrieval of any of the DT device primary port status log 
parameters from the DT Device Status log page by this l_T nexus. If one or more fields in the DT device primary 
port status log parameters have changed since a primary port has been enabled, then the device server may set 
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the intfc bit to one before any of the DT device primary port status log parameters have been retrieved from the 
DT Device Status log page by this l_T nexus. An intfc bit set to zero indicates that no fields in the DT device 
primary port status log parameters have changed since the last retrieval of any of the DT device primary port status 
log parameters by this l_T nexus. An intfc bit set to zero may indicate that none of the DT device primary port 
status log parameters from the DT Device Status log page have been retrieved by this l_T nexus since the last 
hard reset condition. 

A TapeAlert state flag changed (tafc) bit set to one indicates that at least one TapeAlert state flag has changed 
from its previous value since the last retrieval of the TapeAlert Response log page (see 6.1.3) by this l_T nexus. 
The ADC device server sets the tafc bit to zero after retrieval of the TapeAlert Response log page by this l_T 
nexus. A tafc bit set to zero indicates that no TapeAlert state flag has changed. There may not be any difference in 
the TapeAlert state flags upon retrieval if the state changed again between the time of reporting through the tafc 
bit and retrieving the TapeAlert Response log page. This should not be considered an error. Pending TapeAlert 
state flags may affect the reliability of the values returned in other bits within the VHF data descriptor (see 6.1.2.2). 


6.1.2.3 Very high frequency polling delay log parameter 

The very high frequency polling delay log parameter format is shown in table 19. 


Table 19 — Very high frequency polling delay log parameter format 


Bit 

Byte 

7 

6 

5 

4 

3 

2 

1 

0 

0 

(MSB) 

PARAMETER CODE (0001 h) 


1 


(LSB) 

2 

DU (0) DS (1) TSD (0) ETC (0) TMC (00) LBIN(1) LP(1) 

3 

PARAMETER LENGTH (02h) 

4 

(MSB) 

VHF POLLING DELAY 


5 


(LSB) 


The parameter code field shall be set to 0001 h to indicate the very high frequency polling delay log parameter. 

See SPC-3 for descriptions of the du bit, ds bit, tsd bit, etc bit, tmc field, lbin bit, and lp bit. These bits and fields 
shall be set to the values shown in table 19. 

The parameter length field shall be set to 02h to allow transfer of the complete parameter. 

The vhf polling delay field indicates the minimum delay in milliseconds the automation application client should 
wait before requesting the DT Device Status log page again. 
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6.1.2.4 DT device primary port status log parameter(s) 

6.1.2.4.1 DT device primary port status log parameter(s) overview 

The DT device primary port status log parameter(s) format is shown in table 20. 


Table 20 — DT device primary port status log parameter(s) format 


Bit 

Byte 

7 

6 

5 

4 

3 

2 

1 

0 

0 

(MSB) 

PARAMETER CODE 


1 


(LSB) 

2 

DU (0) DS (1) TSD (0) ETC (0) TMC (00) LBIN (1) LP(1) 

3 

PARAMETER LENGTH (n-3) 

4 


DT device primary port status data 


n 




The parameter code field shall be set to the value of the primary port index for the port (see 4.8.1) plus OlOOh. 

See SPC-3 for descriptions of the du bit, ds bit, tsd bit, etc bit, tmc field, lbin bit, and lp bit. These bits and fields 
shall be set to the values shown in table 20. 

The parameter length field contains the length in bytes of DT device primary port status data that follows. 

The DT device primary port status data is determined by the protocol of the port with which the parameter is 
associated. The protocol for each port is reported in the protocol identifier field in the DT Device Primary Port 
mode subpage (see 6.2.2.2) by primary port index value. The DT device primary port status data shall be deter¬ 
mined by table 21 based on the reported protocol for each primary port. 


Table 21 — Port status data format by protocol identifier 


Code 

Description 

Reference 

Oh 

Fibre Channel 

6.1.2.4.2 

1h 

Parallel SCSI 

6.1.2.4.3 

2h - 5h 

Reserved 


6h 

SAS Serial SCSI Protocol 

6.1.2.4.4 

7h - Fh 

Reserved 



6.1.2.4.2 Fibre Channel port status data 

The format of the DT device primary port status data for a Fibre Channel port is shown in table 22. 

A current topology (currtop) bit set to one indicates that the DT device primary port is operating currently in point 
to point mode. A currtop bit set to zero indicates that the DT device primary port is operating currently in 
arbitrated loop mode. The currtop bit shall be ignored when the pic bit is set to zero. 
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Table 22 — Fibre Channel port status data format 


Bit 

Byte 

7 

6 5 4 

3 

2 

1 

0 

0 

CURRTOP 

CURRENT SPEED 

LC 

CONFLICT 

SIGNAL 

PIC 

1 

(MSB) 

CURRENT N_PORT_ID 


3 


(LSB) 

4 


Reserved 


6 



7 

Reserved current fc-al loop id 


The current speed field indicates the bit rate at which the DT device primary port is currently operating. Table 43 
defines the valid values for the current speed field. The current speed field shall be ignored when the pic bit is 
set to zero. 

A login complete (lc) bit set to one indicates that at least one initiator port has completed Process Login (see 
FCP-3) with the DT device on the DT device primary port. A lc bit set to zero indicates that a login has not 
successfully completed through the PRLI phase on the DT device primary port. 

A conflict bit set to one indicates that another device has the required Hard AL_PA (see FC-AL-2) or that no 
AL_PA is available for the DT device primary port. A conflict bit set to zero indicates there is no AL_PA conflict. 

A signal bit set to one indicates that a signal is detected at the DT device primary port (e.g., detection of light for an 
optical medium). A signal bit set to zero indicates a signal is not detected. 

A port initialization complete (pic) bit set to one indicates that the FC_Port state machine is in the ACTIVE state 
(see FC-FS) and the DT device primary port is operating in point-to-point topology, or the most recent Loop Initial¬ 
ization Process (LIP) has completed successfully (see FC-AL-2). A pic bit set to zero indicates that the DT device 
primary port is not in the ACTIVE state and is not synchronized (see FC-FS), or has not successfully completed the 
most recent LIP. 

The current n_port_id field indicates the 24-bit N_Port_ID (see FC-FS) that is assigned to the DT device primary 
port. The current n_port_id field shall be ignored when the pic bit is set to zero. 

The current fc-al loop id field indicates the loop identifier (see FC-AL-2) that is assigned to the DT device 
primary port. The current fc-al loop id field shall be ignored when the pic bit is set to zero or when the currtop 
bit is set to one. 


6.1.2.4.3 SCSI parallel interface port status data 

The format of the DT device primary port status data for a SCSI port that supports parallel transfers (see SPI-5) is 
shown in table 23. 

The current bus mode field indicates the bus mode in which the DT device primary port is operating (see SPI-5). 

The most recent transfer period factor field indicates the transfer period factor that was negotiated most 
recently (see SPI-5). 

The current scsi address field indicates the 8-bit address that is assigned to the DT device primary port. 
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Table 23 — SCSI parallel interface port status data format 


Bit 

Byte 

7 6 5 4 3 

2 1 

0 

0 

Reserved 

CURRENT BUS MODE 

Reserved 

1 

Reserved 

2 

MOST RECENT TRANSFER PERIOD FACTOR 

3 

CURRENT SCSI ADDRESS 


6.1.2.4.4 Serial Attached SCSI port status data 

The format of the DT device primary port status data fora SAS port (see SAS-1.1) is shown in table 24. 


Table 24 — Serial Attached SCSI port status data format 


Bit 

Byte 

7 

6 

5 

4 

3 

2 

1 

0 

0 

NEGOTIATED PHYSICAL LINK RATE 

Reserved 

SIGNAL 

PIC 

1 

(MSB) 

HASHED SAS ADDRESS 


3 


(LSB 

4 

(MSB) 

SAS ADDRESS 


11 


(LSB) 


The negotiated physical link rate field indicates the negotiated physical link rate (see SAS-1.1) for at least one 
phy (see SAS-1.1) that composes the SAS port. 

If the port supports the capability to detect signal at the DT device primary port (e.g., COMINIT detected, see 
SAS-1.1), then a signal bit set to one indicates that a signal is detected by at least one phy that composes the SAS 
port. A signal bit set to zero indicates a signal is not detected by at least one phy that composes the SAS port. If 
the port does not support the capability to detect signal at the DT device primary port, then the signal bit shall be 
set to the value of the pic bit. 

A port initialization complete (pic) bit set to one indicates that the port has successfully completed the link reset 
sequence (see SAS-1.1) for at least one phy that composes the SAS port. When port initialization is complete the 
SAS port is ready to accept connection requests. 

The hashed sas address field contains the hashed version of the SAS address (see SAS-1.1) of the SAS port 
assigned to the DT device primary port. 

The sas address field contains the SAS address (see SAS-1.1) of the SAS port assigned to the DT device primary 
port. 
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6.1.3 TapeAlert Response log page 

Table 25 describes the TapeAlert Response log page. The parameter fields represent the various TapeAlert state 
flags (see 4.6). Table 5 contains a description of the corresponding TapeAlert state flags and the conditions that 
set each state flag to zero. 


Table 25 — TapeAlert Response log page 


Bit 

Byte 

7 

6 

5 

4 

3 

2 

1 

0 

0 

Reserved 

PAGE CODE (12h) 

1 

Reserved 

2 

(MSB) 

PAGE LENGTH (OOOCh) 


3 


(LSB) 

4 

(MSB) 

PARAMETER CODE (OOOOh) 


5 


(LSB) 

6 

DU (0) DS (1) TSD (1) ETC (0) TMC (00) LBIN(1) LP(1) 

7 

PARAMETER LENGTH (08h) 

8 

FLAG01 

FLAG02 

FLAG03 

FLAG04 

FLAG05 

FLAG06 

FLAG07 

FLAG08 

9 

FLAG09 

FLAG 10 

FLAGlI 

FLAG12 

FLAG 13 

FLAG14 

FLAG 15 

FLAG 16 

10 

FLAG17 

FLAG 18 

FLAG19 

FLAG20 

FLAG21 

FLAG22 

FLAG23 

FLAG24 

11 

FLAG25 

FLAG26 

FLAG27 

FLAG28 

FLAG29 

FLAG30 

FLAG31 

FLAG32 

12 

FLAG33 

FLAG34 

FLAG35 

FLAG36 

FLAG37 

FLAG38 

FLAG39 

FLAG40 

13 

FLAG41 

FLAG42 

FLAG43 

FLAG44 

FLAG45 

FLAG46 

FLAG47 

FLAG48 

14 

FLAG49 

FLAG50 

FLAG51 

FLAG52 

FLAG53 

FLAG54 

FLAG55 

FLAG56 

15 

FLAG57 

FLAG58 

FLAG59 

FLAG60 

FLAG61 

FLAG62 

FLAG63 

FLAG64 


See SPC-3 for a description of the page code field. 


The page length field shall be set to OOOCh to allow the transfer of the complete log page. 

The parameter code field shall be set to OOOOh to indicate the single log parameter. 

See SPC-3 for descriptions of the du bit, ds bit, tsd bit, etc bit, tmc field, lbin bit, and lp bit. These bits and fields 
shall be set to the values shown in table 25. 

The parameter length field shall be set to 08h to allow transfer of the complete parameter. 

A flagxx bit set to one indicates the TapeAlert state flag is set. A flagxx bit set to zero indicates the TapeAlert 
state flag is not set. 
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6.1.4 Requested Recovery log page 

6.1.4.1 Requested Recovery log page overview 

Table 26 describes the Requested Recovery log page. When the DT device is unable to complete an action (e.g., 
a medium load or unload) the DT device may set the rrqst bit to one in the very high frequency data log 
parameter (see 6.1.2.2) to request that the automation device perform a recovery action. The application client is 
able to obtain a list of alternative requested recovery actions by reading the Requested Recovery log page. 


Table 26 — Requested Recovery log page 


Bit 

Byte 

7 

6 

5 

4 

3 

2 

1 

0 

0 

Reserved 

PAGE CODE (13h) 

1 

Reserved 

2 

(MSB) 

PAGE LENGTH (n-3) 


3 


(LSB) 

4 


Requested recovery log parameters 


n 




See SPC-3 for a description of the page code field and the page length field. 


Table 27 defines the Requested Recovery log page parameter codes. 

Table 27 — Requested Recovery log page parameter codes 


Parameter code 

Description 

Reference 

OOOOh 

Recovery procedures 

6.1.4.2 

0001 h-7FFFh 

Reserved 


8000h - FFFFh 

Vendor-specific 
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6.1.4.2 Recovery procedures log parameter 


The recovery procedures log parameter format is shown in table 28. 

Table 28 — Requested recovery log parameter format 


Bit 

Byte 

7 6 5 4 3 2 1 0 

0 

(MSB) 

1 

PARAMETER CODE (OOOOh) 

(LSB) 

2 

DU (1 ) DS (1) TSD (1) ETC (0) TMC (00) LBIN (1) LP(1) 

3 

PARAMETER LENGTH (n-3) 


Recovery procedures list 

4 

First recovery procedure 



n 

Last recovery procedure 


See SPC-3 for descriptions of the du bit, ds bit, tsd bit, etc bit, tmc field, lbin bit, and lp bit. These bits and fields 
shall be set to the values shown in table 28. 

The parameter length field indicates the number of recovery procedure bytes that follow. 

The parameter code field shall be set to OOOOh to indicate the recovery procedures log parameter. 

The recovery procedures list contain recovery procedures (see table 29) listed in order from the most preferred to 
the least preferred procedure. When multiple recovery procedures are available, the most preferred procedure 
shall be the first in the list (i.e., in byte 4), and the other procedures listed in decreasing order of preference. The 
automation device may select any recovery procedure, regardless of position in the list. 

Each recovery procedure consists of one or more actions to be performed. When the inxtn bit in the VHF data 
descriptor (see 6.1.2.2) is set to one, the parameter shall report only code OOh (i.e., Recovery not requested). If a 
failure occurs in performing one of the actions in a procedure, then an appropriate list of requested recovery proce¬ 
dures may be reported. 
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Recovery procedures do not persist across a power cycle. 

Table 29 — Recovery procedures 


Recovery Procedure 

Description 

OOh 

Recovery not requested 

Olh 

Recovery requested, no recovery procedure defined 

02h 

Push medium 

03h 

Remove and re-insert medium 

04 h 

Issue a command to unload the medium, then remove and re-insert the 
medium 

05h 

Cycle power to DT device 

06h 

Issue a command to load the medium 

07h 

Issue a command to unload the medium 

08h 

Issue LOGICAL UNIT RESET task management function 

09h 

No recovery procedure defined. Contact service organization 

OAh 

Issue a command to unload the medium, then remove and quarantine the 
medium 

OBh 

Do not insert medium. Contact service organization 

OCh 

Issue a command to unload the medium, then remove medium and contact 
service organization 

ODh 

Request creation of a DT device error log 

OEh 

Retrieve a DT device error log 

OFh 

Modify configuration to allow microcode update (see 6.2.2.3.2) and re-insert 
medium. 

10h — 7Fh 

Reserved 

80h - FFh 

Vendor-specific procedures 


If the Requested Recovery log page is requested when the rrqst bit n the VHF data descriptor (see 6.1.2.2) is set 
to zero, then a recovery procedure of OOh (i.e., Recovery not requested) shall be reported. 

If the requested recovery procedure causes the DT device to eject the medium, then the automation device shall 
ensure there is not conflict between the motion of a medium transport element and the medium before initiating 
that recovery action. 

If the requested recovery procedure is 09h (i.e., Contact service organization), then the automation device shall not 
issue a load or unload command or attempt to manipulate the medium physically. 

If the requested recovery procedure is OAh (i.e., Issue a command to unload the medium, then remove and 
quarantine medium), then the medium should not be loaded in a DT device. 
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If the requested recovery procedure is OBh (i.e., Do not insert medium), then a non-recoverable error has occurred 
and insertion of a medium may cause damage. If the OBh recovery procedure is requested, then the raa bit n the 
VHF data descriptor shall be set to zero, and no other recovery procedures shall be reported. 

If the requested recovery procedure is OCh (i.e., issue a command to unload the medium, then remove medium 
and contact service organization), then a non-recoverable error has occurred and insertion of a new medium may 
cause damage. When recovery procedure OCh is requested and the medium has been removed, then the raa bit n 
the VHF data descriptor (see 6.1.2.2) shall be set to zero, and no other recovery procedures shall be reported. 


6.1.5 Service Buffers Information log page 

The Service Buffers Information log page (see table 30) describes the vendor-specific service buffers (see 6.1.4.2) 
that are available from the ADC device server that may be retrieved via a READ BUFFER command (see SPC-3). 
Using the assigned buffer ID, an application client is able to use descriptor mode (see SPC-3) to retrieve the size of 
the service buffer. An application client is able to use data mode (see SPC-3) to retrieve the service buffer 
according to the allowable service buffer retrieval conditions provided by the log parameter. 

An ADC device server that implements the Service Buffers Information log page shall implement one or more log 
parameters. Each implemented log parameter shall represent a unique service buffer. Parameters shall not be 
changed via a LOG SELECT command. 

An ADC device server shall save a copy of a service buffer (e.g., a snapshot) in response to: 

a) vendor-specific events; or 

b) processing a READ BUFFER command using descriptor mode with the buffer id field set to a value that 
matches the buffer id field value of one of the service buffers described by a parameter of the Service 
Buffers Information log page for which an unread copy of the service buffer does not exist. 

An ADC device server that implements the Service Buffers Information log page should indicate Retrieve a DT 
device error log (see table 29) in the recovery procedures when a copy of a service buffer of any service buffer 
exists. The copy of a service buffer should be maintained until the service buffer associated with the buffer ID in the 
READ BUFFER command is completely read. The copy of the service buffer may be cleared on a: 

c) vendor-specific event; 

d) LOGICAL UNIT RESET; 

e) TARGET RESET; or 

f) POWER ON RESET. 


Table 30 — Service Buffers Information log page 


Bit 

Byte 

7 

6 

5 

4 

3 

2 

1 

0 

0 

Reserved 

PAGE CODE (15h) 

1 

Reserved 

2 

(MSB) 

PAGE LENGTH (n-3) 


3 


(LSB) 

4 


Service buffers information log parameters 


n 
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See SPC-3 for a description of the page code field and the page length field. 
The service buffer information log parameter format is shown in table 31. 


Table 31 — Service buffer information log parameter format 


Bit 

Byte 

7 6 5 4 

3 2 10 

0 

(MSB) 

1 

PARAMETER CODE 

(LSB) 

2 

DU (0) DS (1) TSD (1) ETC (0) TMC (00) LBIN(1) LP(1) 

3 

PARAMETER LENGTH (n-3) 

4 

BUFFER ID 

5 

Reserved tu 

NMP NMM OFFLINE PD 

6 

Reserved 

CODE SET 

7 

Reserved 

8 


n 

SERVICE BUFFER TITLE 


The parameter code field is defined in table 32. 


Table 32 — Service buffer information parameter codes 


Code 

Description 

OOOOh - OOFFh 

OlOOh - 7FFFh 

8000h - FFFFh 

Service buffer identifier 

Reserved 

Vendor-specific 


See SPC-3 for descriptions of the du bit, ds bit, tsd bit, etc bit, tmc field, lbin bit, and lp bit. These bits and fields 
shall be set to the values shown in table 31. 

The parameter length field contains the length in bytes of service buffer information data that follows. 

See SPC-3 for a description of the buffer id field. 

The tu bit, nmp bit, nmm bit, offline bit, and pd bit are collectively referred to as the service buffer retrieval control 
byte, and are described in this subclause. 

A temporarily unavailable (tu) bit set to one indicates that the service buffer identified by the contents of the buffer 
id field is temporarily unavailable for retrieval from the device server for reasons outside the scope of this standard. 
A tu bit set to zero indicates that the service buffer identified by the contents of the buffer id field is able to be 
retrieved from the device server. 

A no medium present (nmp) bit set to one indicates that the device server is unable to retrieve the service buffer 
identified by the contents of the buffer id field when a medium is present in the DT device (see 4.4). A nmp bit set 
to zero indicates that the device server is able to retrieve the service buffer identified by the contents of the buffer 
id field when a medium is present in the DT device. 
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A no medium mounted (nmm) bit set to one indicates that the device server is unable to retrieve the service buffer 
identified by the contents of the buffer id field when a medium is mounted in the DT device (see 4.4). A nmm bit set 
to zero indicates that the device server is able to retrieve the service buffer identified by the contents of the buffer 
id field when a medium is mounted in the DT device. 

An offline bit set to one indicates that the device server is unable to retrieve the service buffer identified by the 
contents of the buffer id field when the RMC device server is online (see 6.2.2.3.2). An offline bit set to zero 
indicates that the device server is able to retrieve the service buffer identified by the contents of the buffer id field 
when the RMC device server is online. 

A port disabled (pd) bit set to one indicates that the device server is unable to retrieve the service buffer identified 
by the contents of the buffer id field is when the DT device primary port(s) associated with the RMU logical unit 
are enabled (see 6.2.2.2.2). A pd bit set to zero indicates that the device server is able to retrieve the service buffer 
identified by the contents of the buffer id field when the DT device primary port(s) associated with the RMU logical 
unit are enabled. 

See SPC-3 for a description of the code set field. 

The service buffer title field contains ASCII information describing the service buffer identified by the contents of 
the buffer id field. The data in this field shall be formatted as a single character string line and shall contain only 
graphic codes (i.e., code values 20h through 7Eh) and shall be terminated with a NULL (OOh) character. 
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6.2 Mode parameters 

6.2.1 Mode parameters overview 

This subclause defines the descriptors and pages for mode parameters used with ADC device servers. 

See SPC-3 for a description of the mode parameter list, including the mode parameter header and mode block 
descriptor. 

The medium type field in the mode parameter header is reserved for ADC device servers. 

The device-specific parameter field in the mode parameter header is reserved for ADC device servers. 

The density code field in the mode parameter block descriptor is reserved for ADC device servers. 

The ADC device server may require that the DT device primary port(s) be disabled before certain mode param¬ 
eters are allowed to be changed (see 6.2.2.2). 
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The mode page codes for ADC device servers are shown in table 33. 

Table 33 — Mode page codes 


Page code 

Subpage 

code 

Description 

Reference 

02h 

OOh 

Disconnect-Reconnect mode page 

SPC-3 

OAh 

OOh 

Control mode page 

SPC-3 

OAh 

Olh 

Control Extension page 

SPC-3 

OEh 

Olh 

Target Device subpage b 

6.2.2.1 

OEh 

02h 

DT Device Primary Port subpage b 

6.2.2.2 

OEh 

03h 

Logical Unit subpage b 

6.2.2.3 

OEh 

04 h 

Target Device Serial Number subpage b 

6.2.2.4 

15h 

OOh 

Restricted 


18h 

OOh 

Protocol Specific LUN mode page 

SPC-3 

18h 

Olh-FEh 

(see specific SCSI transport protocol) 

SPC-3 

19h 

OOh 

Protocol Specific Port mode page 

SPC-3 

19h 

Olh-FEh 

(see specific SCSI transport protocol) 

SPC-3 

1A 

OOh 

Power Condition page 

SPC-3 

ICh 

OOh 

Informational Exceptions Control mode page 

SSC-3 

20h - 3Eh 

OOh - FEh 

Vendor-specific 


01 h - 3Eh 

FFh 

Return all subpages a 

SPC-3 

3Fh 

OOh 

Return all pages a 

SPC-3 

3Fh 

FFh 

Return all pages and subpages a 

SPC-3 

All page code and subpage code combinations not shown in this table are reserved. 

a valid only for the MODE SENSE (see SPC-3) command. 

b This subpage contains one or more descriptors. The descriptors may be included in any order. On a MODE 
SENSE command, all descriptors supported by the ADC device server shall be returned. On a MODE 
SELECT command (see SPC-3), all of the supported descriptors shall be included. Any descriptor included 
shall be included in its entirety. 
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6.2.2 ADC Device Server Configuration mode page 
6.2.2.1 Target Device subpage 

The Target Device subpage is variable length and contains SCSI target device name identification descriptors (see 
SPC-3) of the DT device. The subpage is defined in table 34. 


Table 34 — Target Device subpage 


Bit 

Byte 

7 

6 

5 

4 

3 

2 

1 

0 

0 

PS 

SPF (1b) 

PAGE CODE (OEh) 

1 

SUBPAGE CODE (01h) 

2 

(MSB) 

PAGE LENGTH (n-3) 


3 


(LSB) 

4 

Reserved mtdn 

5 

Reserved 

6 

Reserved 

7 

Reserved 


Identification descriptor list 

8 


Identification descriptor (first) 









Identification descriptor (last) 


n 




See SPC-3 for a description of the ps bit, spf bit, page code field, subpage code field, and page length field. The 
spf bit, page code field, and subpage code field shall be set to the values shown in table 34. 
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The modify target device name (mtdn) field and identification descriptors are used to modify and report modifica¬ 
tions to the DT device SCSI target device names (see SPC-3), as defined in table 35. 


Table 35 — mtdn field 


Value 

MODE SENSE command a 

MODE SELECT command a 

00b 

The mtdn field shall be set to zero 
for a MODE SENSE command. The 
identification descriptors shall con¬ 
tain the currently assigned values. 

Do not modify the DT device’s SCSI target 
device names. The identification descriptors 
shall be ignored. 

01b 

Invalid 

Use the logical unit identifier for LUN 0 as the DT 
device SCSI target device name. The identifica¬ 
tion descriptors shall be ignored. 

10b 

Set the DT device’s SCSI target device names 
to the manufacturer’s default value. The identifi¬ 
cation descriptors shall be ignored. 

11b 

Set the DT device’s SCSI target device names 
to the values in the identification descriptors. 

a See SPC-3. 


The identification descriptors are the same as those in the Device Identification VPD page (see SPC-3). Only 
identification descriptors with the association field set to 10b (i.e., target device) shall be used. On MODE 
SELECT commands, if any identification descriptor contains an association field set to a value other than 10b, 
then the ADC device server shall return CHECK CONDITION status, setting the sense key to ILLEGAL REQUEST 
and the additional sense code to INVALID FIELD IN PARAMETER LIST. 

A device server processing a MODE SELECT command with parameter data containing the Target Device 
subpage and the mtdn field set to 01b shall not modify the DT device’s SCSI target device name and shall return 
CHECK CONDITION status with the sense key set to ILLEGAL REQUEST and the additional sense code set to 
INVALID FIELD IN PARAMETER LIST if: 

a) the DT device supports multiple primary ports; 

b) a transport protocol for a primary port in the DT device mandates uniqueness of the SCSI target device 
name and the name of a SCSI logical unit within the DT device; or 

c) a transport protocol for a primary port in the DT device mandates a name format for the SCSI target device 
name that differs from the name format of all of the logical unit identifiers of LUN 0. 
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6.2.2.2 DT Device Primary Port subpage 
6.2.2.2.1 DT Device Primary Port subpage overview 

The DT Device Primary Port subpage contains descriptors that allow the DT device’s primary ports to be 
configured, independent of the port type receiving the command (e.g., a Fibre Channel DT device primary port may 
be configured via the DT device’s ADI port). 

The DT Device Primary Port subpage is variable length, and consists of a mode subpage header followed by one 
or more descriptors (see table 36). 


Table 36 — DT Device Primary Port subpage 


Bit 

Byte 

7 

6 

5 

4 

3 

2 

1 

0 

0 

PS 

SPF (1b) 

PAGE CODE (OEh) 

1 

SUBPAGE CODE (02h) 

2 

(MSB) 

PAGE LENGTH (n-3) 


3 


(LSB) 


DT device primary port descriptor list 

4 


DT device primary port descriptor (first) 









DT device primary port descriptor (last) 


n 




See SPC-3 for a description of the ps bit, spf bit, page code field, subpage code field, and page length field. The 
spf bit, page code field, and subpage code field shall be set to the values shown in table 36. 


6.2.2.2.2 DT device primary port descriptor format 

The DT device primary port descriptor format is shown in table 37. 


Table 37 — DT device primary port descriptor format 


Bit 

Byte 

7 

6 

5 

4 

3 

2 

1 

0 

0 

PRIMARY PORT INDEX 

1 

Reserved protocol identifier 

2 

(MSB) 

ADDITIONAL DESCRIPTOR LENGTH (n-3) 


3 


(LSB) 

4 


DT device primary port descriptor parameters 


n 
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The primary port index field contains the primary port index (see 4.8.1) assigned by the DT device. 

The protocol identifier field indicates the type of protocol supported by the DT device primary port (see SPC-3). 
For the MODE SELECT command, if the protocol identifier specified by the protocol identifier field does not 
match the protocol of the target port specified by the relative target port field, the device server shall terminate 
the command with CHECK CONDITION status with the sense key set to ILLEGAL REOUEST and the additional 
sense code set to INVALID FIELD IN PARAMETER LIST. 

The additional descriptor length field specifies the number of descriptor bytes that follow. 

The DT device primary port descriptors vary based on the value in the protocol identifier field (see table 38). 


Table 38 — Primary port descriptor by protocol identifier value 


Value 

Description 

Reference 

Oh 

Fibre Channel descriptor 

6.2.2.2.3 

1h 

Parallel SCSI descriptor 

6.2.2.2.4 

2h-5h 

Reserved 


6h 

Serial Attached SCSI descriptor 

6.2.2.2.5 

7h - Fh 

Reserved 



6.2.2.2.3 Fibre Channel descriptor parameter format 

Table 39 describes the format of the descriptor parameter for Fibre Channel port types. 


Table 39 — Fibre Channel descriptor parameter format 


Bit 

Byte 

7 

6 

5 

4 

3 2 

1 

0 

0 

p2p 

TOPLOCK 

RHA 

LIV 

MPN 

Rsvd 

PE 

1 

Reserved 

TOPORD 

SPDLOCK SPEED 

2 

Reserved 

3 

Rsvd FC-AL LOOP ID 

4 


PORT NAME 


11 




A DT device receiving a MODE SELECT command (see SPC-3) for an enabled DT device primary port, where the 
command attempts to change the value of the mpn field, liv bit, rha bit, toplock bit, p2p bit, speed field, spdlock 
bit, topord bit, fc-al loop id field, or port name field, shall return CHECK CONDITION status with the sense key 
set to ILLEGAL REOUEST and the additional sense code set to INVALID FIELD IN PARAMETER LIST. If the DT 
device primary port is disabled, then the DT device may change the mpn field, liv bit, rha bit, toplock bit, p2p bit, 
speed field, spdlock bit, fc-al loop id field, or port name field and enable the DT device primary port with the 
same MODE SELECT command. 


53 


Working Draft Automation/Drive Interface Commands - 2 (ADC - 2) 







































10 July 2007 


T10/1741-D Revision8 


The point-to-point (p2p) bit, topology order (topord) bit, and topology lock (toplock) bit define the method by 
which the DT device primary port connects to the service delivery subsystem. Table 40 defines how the toplock 
bit, p2p bit, and topord bit interact. 


Table 40 — toplock bit, p2p bit, and topord bit interaction 


TOPLOCK 

topord 

p2p 

Description 

0 

0 

X 

Vendor-specific behavior for negotiating topology (see 
FC-FS). 

0 

1 

0 

The port attempts to negotiate operation in FC-AL 
topology first. If unsuccessful, then the port negotiates 
operation in point-to-point mode. 

0 

1 

1 

The port attempts to negotiate operation in 
point-to-point mode first. If unsuccessful then negoti¬ 
ates to FC-AL topology. 

1 

X 

0 

The port is configured to operate in arbitrated loop 
mode. 

1 

X 

1 

The port is configured to operate in point-to-point mode 
and the rha bit, liv bit, and fc-al loop id field shall be 
ignored in a MODE SELECT command. 


The loop ID valid (liv) bit and require hard address (rha) bit are described in table 41. 


Table 41 — Effect of liv and rha bits 




Description 

0b 

0b 

The fc-al loop id field shall be ignored. 

0b 

1b 

This bit value combination is invalid. A MODE SELECT command (see SPC-3) shall be termi¬ 
nated with a CHECK CONDITION status. The sense key shall be set to ILLEGAL REQUEST 
and the additional sense code shall be set to INVALID FIELD IN PARAMETER LIST. 

1b 

0b 

The DT device primary port attempting to operate in an arbitrated loop topology shall use the 
value in the fc-al loop id field to request the Hard AL_PA during the LIHA Loop Initialization 
Sequence (see FC-AL-2) provided it has not already obtained its address. The DT device pri¬ 
mary port may obtain its address during any of the Loop Initialization Sequences. 

1b 

1b 

The DT device primary port attempting to operate in an arbitrated loop topology shall use the 
value in the fc-al loop id field to obtain its address during the LIHA Loop Initialization 

Sequence. The DT device primary port shall not obtain an address during the LIFA or LIPA 

Loop Initialization Sequences if the value of the fc-al loop id field does not match the previ¬ 
ously obtained address. The DT device primary port shall not attempt to obtain an address dur¬ 
ing the LISA Loop Initialization Sequence. If there is a conflict for the Hard Address (see 
FC-AL-2) during loop initialization, then the DT device primary port shall enter the non participat¬ 
ing state. If the DT device primary port detects loop initialization while in the nonparticipating 
state, then the DT device primary port shall again attempt to get the address specified by the 
value in the fc-al loop id field. 
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The modify port name (mpn) field and port name field are used to modify and report modifications to the DT device 
primary port’s name identifier (see FC-FS), as defined in table 42. 


Table 42 — mpn field 


Code 

MODE SENSE command a 

MODE SELECT command a 

00b 

The mpn field shall be set to zero for a MODE 
SENSE command. The port name field shall 
contain the currently assigned value. 

Do not modify the DT device primary port’s name 
identifier (see FC-FS). The port name field shall be 
ignored. 

01b 

Invalid 

Reserved. 

10b 

Set the DT device primary port’s name identifier to 
the manufacturer’s default value. The value in the 
port name field shall be ignored. 

11b 

Set the DT device primary port’s name identifier to 
the value in the port name field. 

a See SPC-3. 


A port enable (pe) bit set to one enables the DT device primary port (see 4.8). When the pe bit is set to zero, the DT 
device shall not enable the DT device primary port’s drivers and the DT device primary port shall not respond to 
primitives (see FC-AL-2). 


A speed lock (spdlock) bit set to one forces the DT device primary port to only operate in the speed selected by 
the speed field. A spdlock bit set to zero allows the DT device primary port to negotiate the speed (see FC-FS). 
When the spdlock bit is set to zero on a MODE SELECT command, the speed field shall be ignored. 

The speed field contains the bit rate (see table 43) in which the DT device primary port is configured to operate. 


Table 43 — speed field 


Code 

Speed 

000b 

1 Gb/sec 

001b 

2 Gb/sec 

010b 

4 Gb/sec 

011b 

8 Gb/sec 

100b 

10 Gb/sec 

101b - 111b 

Reserved 


The fc-al loop id field contains the loop identifier that shall be used to represent the hard assigned AL PA (see 
FC-AL-2). 


The port name field contains the DT device’s primary port name identifier (see FC-FS). When the mpn field is set 
to 11b (see table 42), the port name field contains an NAA identifier type name identifier (see SPC-3). 
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6.2.2.2.4 Parallel SCSI descriptor parameter format 

Table 44 defines the format of the descriptor parameter for parallel SCSI port types. 


Table 44 - Parallel SCSI descriptor parameter format 


Bit 

Byte 

7 6 5 

4 3 

2 1 

0 

0 

Reserved 

BMQ 

BUS MODE 

PE 

1 

Reserved 

2 

minimum transfer period factor 

3 

SCSI ADDRESS 


A DT device receiving a MODE SELECT command (see SPC-3) for an enabled DT device primary port, where the 
command attempts to change the value of the bus mode field, bmq field, minimum transfer period factor field, or 
SCSI ADDRESS field, shall return CHECK CONDITION status with the sense key set to ILLEGAL REQUEST and the 
additional sense code set to INVALID FIELD IN PARAMETER LIST. If the DT device primary port is disabled, then 
the DT device may change the bus mode field, bmq field, minimum transfer period factor field, or scsi address 
field and enable the DT device primary port with the same MODE SELECT command. 

The bus mode qualifier (bmq) field (see table 45) qualifies the effect that the bus mode field has on the DT device 
primary port. 


Table 45 — bmq field 


Code 

Effect 

00b 

The DT device shall ignore the value of the bus mode field. 

01b 

The DT device operates the DT device primary port as specified by the bus 
mode field. The DT device primary port shall not drive the DIFFSENS line with 
the associated voltage and current characteristics (see SPI-5). 

10b 

Reserved 

11b 

The DT device operates the DT device primary port in the mode specified by the 
bus mode field. The DT device primary port shall drive the DIFFSENS line with 
the associated voltage and current characteristics (see SPI-5). 


The bus mode field defines the transmission mode that the DT device shall use in the transceiver mode field of 
the Negotiated Settings mode subpage (see SPI-5) for this DT device primary port. 

A port enable (pe) bit set to one enables the DT device primary port to respond to selections on the SCSI bus (see 
SPI-5). A pe bit set to zero prevents the DT device primary port from responding to or attempting selections, 
reselections, or hard resets on the SCSI bus (see 4.8). 

The minimum transfer period factor field defines the minimum transfer period factor that the DT device shall use 
when negotiating transfer agreements (see SPI-5) for this DT device primary port. DT devices that are not able to 
support the identified minimum transfer period factor may enter negotiation using the next larger supported transfer 
period factor. 

The scsi address field specifies the address that the DT device primary port shall respond to on the SCSI bus. 
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6.2.2.2.5 Serial Attached SCSI descriptor parameter format 

Table 46 describes the format of the descriptor parameter for SAS port types. 


Table 46 — Serial Attached SCSI descriptor parameter format 


Bit 

Byte 

7 

6 

5 

4 

3 

2 

1 

0 

0 

Reserved 

MPI 

Rsvd 

PE 

1 


Reserved 


3 



4 


PORT IDENTIFIER 


11 




A DT device receiving a MODE SELECT command (see SPC-3) for an enabled DT device primary port, where the 
command attempts to change the port identifier (see table 47), shall return CHECK CONDITION status with the 
sense key set to ILLEGAL REOUEST and the additional sense code set to INVALID FIELD IN PARAMETER LIST. 
If the DT device primary port is disabled, then the automation application client may change the DT device port 
identifier and enable the DT device primary port with the same MODE SELECT command. 

The modify port identifier (mpi) field and port identifier field control the DT device primary SAS port identifier (see 
SAS-1.1) as defined in the table 47. 


Table 47 — mpi field 


Code 

MODE SENSE command a 

MODE SELECT command a 

00b 

The mpi field shall be set to zero for a MODE 
SENSE command. The port identifier field 
shall contain the currently assigned port identi¬ 
fier value. 

Do not modify the DT device primary port identifier 
(see SAS-1.1). The port identifier field shall be 
ignored. 

01b 

Invalid 

Reserved 

10b 

Set the DT device primary port identifier to the man¬ 
ufacturer’s default value. The value in the port iden¬ 
tifier field shall be ignored. 

11b 

Set the DT device primary port identifier to the value 
contained in the port identifier field. 

a See SPC-3. 


A port enable (pe) bit set to one enables the DT device primary SAS port. When the pe bit is set to zero, the DT 
device shall not enable any phy contained in the DT device primary SAS port (see SAS-1.1). 

The port identifier field contains the DT device’s primary SAS port identifier (see SAS-1.1). When the mpi field is 
set to 11b, the port identifier field shall contain an NAA IEEE Registered format identifier (see SAS-1.1). 


57 


Working Draft Automation/Drive Interface Commands - 2 (ADC - 2) 









































10 July 2007 


T10/1741-D Revision8 


6.2.2.3 Logical Unit subpage 

6.2.2.3.1 Logical Unit subpage overview 

The Logical Unit subpage is variable-length, and consists of a mode subpage header followed by one or more 
descriptors. The descriptors may be included in any order. On a MODE SENSE command (see SPC-3), all logical 
units supported by the DT device (i.e., ADC logical units, RMC logical units, and SMC logical units) other than 
W-LUNs (see SPC-3) shall have descriptors returned. On a MODE SELECT command (see SPC-3), all of the 
supported descriptors shall be included. Any descriptor included shall be included in its entirety. 

Table 48 describes the Logical Unit subpage. 


Table 48 — Logical Unit subpage 


Bit 

Byte 

7 

6 

5 

4 

3 

2 

1 

0 

0 

PS 

SPF (1b) 

PAGE CODE (OEh) 

1 

SUBPAGE CODE (03h) 

2 

(MSB) 

PAGE LENGTH (n-3) 


3 


(LSB) 


Logical unit descriptor list 

4 


Logical unit descriptor (first) 









Logical unit descriptor (last) 


n 




See SPC-3 for a description of the ps bit, spf bit, page code field, subpage code field, and page length field. The 
spf bit, page code field, subpage code field shall be set to the values shown in table 48. 

The logical unit descriptors are described in this subclause. 
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6.2.2.3.2 RMC logical unit descriptor format 

The descriptor format for an RMC logical unit (e.g., device type field contains Olh in the case of a 
sequential-access device (see SPC-3)) is defined in table 49. 


Table 49 — RMC logical unit descriptor format 


Bit 

Byte 

7 

6 

5 

4 

3 

2 

1 

0 

0 

LOGICAL UNIT INDEX 

1 

DEVICE TYPE 

2 

(MSB) 

ADDITIONAL DESCRIPTOR LENGTH (n-3) 


3 


(LSB) 

4 


LOGICAL UNIT NUMBER 


5 



6 

MLUD 

Reserved offline enable 

7 

Reserved 

AUH 

SUHO 

AMO 

AUTOLOAD MODE 

8 

MUE MUP 

Reserved 

MANDROFF 

CP 

DRMODE Reserved wp 

9 

CURRENT DENSITY 

10 

Reserved 

11 

Reserved 

12 

Reserved 

13 

Reserved 

14 

Reserved 

15 

Reserved 


Identification descriptor list 

16 


Identification descriptor (first) 









Identification descriptor (last) 


n 




The logical unit index field contains a value assigned by the DT device at power on that uniquely identifies the 
RMC logical unit from all other logical units on the DT device, independent of device server. This field shall not be 
changeable. The ADC device server shall terminate a MODE SELECT command that attempts to change the value 
in the logical unit index field with CHECK CONDITION status with the sense key to ILLEGAL REQUEST and the 
additional sense code set to INVALID FIELD IN PARAMETER LIST. 

The device type field defines the type of command set supported by the RMC logical unit. The device type field 
contains the same value that would be returned by the RMC logical unit in the peripheral device type field for an 
INQUIRY command (see SPC-3). 

The additional descriptor length field specifies the number of descriptor bytes that follow. 


Working Draft Automation/Drive Interface Commands - 2 (ADC - 2) 
















































10 July 2007 


T10/1741-D Revision8 


The logical unit number field specifies, for the RMC logical unit when accessed through the DT device primary 
port(s): 


a) the LUN if access controls are not in effect; or 

b) the default LUN if access controls are in effect (see SPC-3). 

The logical unit number field contains the first two bytes (i.e., bytes 0 and 1) of a single level logical unit structure 
or the contents of a two byte extended logical unit address (see SAM-3). The logical unit number field shall be 
ignored if the enable bit is set to zero. The ADC device server shall return a CHECK CONDITION status to a 
MODE SELECT command (see SPC-3) when multiple descriptors with the enable bit set to one have the same 
value in the logical unit number field. The sense key shall be set to ILLEGAL REQUEST and the additional sense 
code shall be set to INVALID FIELD IN PARAMETER LIST. 

The modify logical unit descriptor (mlud) field (see table 50) modifies and reports modifications to the RMC logical 
unit’s device identifiers. 


Table 50 — mlud field 


Code 

MODE SENSE command a 

MODE SELECT command a 

00b 

The mlud field shall be set to zero for 
a MODE SENSE command. The 
identification descriptors shall contain 
the currently assigned values. 

Do not modify the RMC logical unit’s device identi¬ 
fiers. The identification descriptors shall be 
ignored. 

01b 

Invalid 

Reserved 

10b 

Set the RMC logical unit’s device identifiers to the 
manufacturer’s default values. The identification 
descriptors shall be ignored. 

11b 

Set the RMC logical unit’s device identifiers to the 
values in the identification descriptors. 

a See SPC-3. 


If the offline bit is set to one, then the RMC device server shall return CHECK CONDITION status with the sense 
key set to NOT READY and the additional sense code set to LOGICAL UNIT NOT READY, OFFLINE to all 
commands that require the RMC logical unit to be in the ready state. If the offline bit is set to zero, then the RMC 
device server shall respond normally to commands. 

An enable bit set to one specifies that the DT device primary port(s) associated with the RMC logical unit shall be 
responsive to commands and task management requests received on the DT device primary port(s). An enable bit 
set to zero specifies that the DT device primary port(s) associated with the RMC logical unit shall not respond to 
commands and task management requests received on the DT device primary port(s) and the associated RMC 
logical unit number shall not be included in the logical unit inventory (see SPC-3) for all I T nexuses associated 
with a DT device primary port. The enable bit has no effect on the access to the RMC device server through the 
ADI port. 

If the enable bit is changed from one to zero, then the RMC device server shall implicitly abort all commands in its 
task set received on a DT device primary port and report CHECK CONDITION status with the sense key set to 
ABORTED COMMAND and the additional sense code set to LOGICAL UNIT COMMUNICATION FAILURE for 
each command. All remaining device servers (e.g., local SMC device server, ADC device server) in the DT device 
shall report a change in the logical unit inventory (see SPC-3) to any application clients connected through a DT 
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device primary port. The enable bit changing from one to zero shall have no effect on commands and task 
management requests received on an ADI port. 

An automatic unload hold (auh) bit set to one disables ejecting the medium when the medium is unloaded due to 
DT device specific conditions (e.g., cleaning complete, invalid medium type, microcode update complete, unsup¬ 
ported format, or other error conditions detected by the DT device). An auh bit set to zero shall have no effect on 
the ejecting of the medium. The auh bit does not affect the unload operation initiated via the physical user interface 
of the DT device. 

A SCSI unload hold override (suho) bit set to one specifies the hold bit in the LOAD UNLOAD command (see 
SSC-2) shall be ignored by the RMC device server and the medium shall not be ejected. A suho bit set to zero 
specifies the hold bit in the LOAD UNLOAD command shall control if the medium is ejected or not, as processed 
by the RMC device server. The suho bit shall not affect LOAD UNLOAD commands processed by the ADC device 
server. 

An autoload mode override (amo) bit set to one specifies the load process shall be controlled by the autoload 
mode field (see table 51), overriding the settings in the Control mode page autoload mode field (see SPC-3). An 
amo bit set to zero specifies that the settings in the Control mode page autoload mode field shall be used to 
control the load process. 

The autoload mode field (see table 51) specifies the action to be taken by the DT device when a medium is 
inserted. If the amo bit is set to zero, then the autoload mode field shall be ignored. 


Table 51 — autoload mode field 


Code 

Definition 

000b 

Medium shall be loaded for full access. 

001b 

Medium shall be loaded for medium auxiliary memory access only. 

010b 

Medium shall not be loaded. 

011b- 111b 

Reserved 


A microcode update enable (mue) bit set to one allows the DT device to prepare to accept a medium containing a 
microcode image. A description of this preparation is outside the scope of this standard. The behavior when the 
mue bit is set to zero is vendor specific. The mue bit shall be set to zero by the DT device after the microcode 
update process completes or is aborted. 

A microcode update protect (mup) bit set to one shall prevent the DT device from performing a microcode update 
process upon the loading of a medium containing a microcode image. A mup bit set to zero shall not prevent the DT 
device from performing a microcode update process upon the loading of a medium containing a microcode image. 

A manual disaster recovery off (mandroff) bit set to one specifies that the DT device shall exit disaster recovery 
mode when an application client sets the drmode bit to zero. A mandroff bit set to zero specifies that the DT 
device shall exit disaster recovery mode upon detection of a vendor-specific event. 

A clean protect (cp) bit set to one shall prevent the DT device from performing a cleaning operation upon the 
loading of a cleaning medium. A cp bit set to zero shall not prevent the DT device from performing a cleaning 
operation upon the loading of a cleaning medium. 

A disaster recovery mode (drmode) bit set to one specifies that the DT device shall operate in disaster recovery 
mode. A drmode bit set to zero specifies that the DT device shall not operate in disaster recovery mode. The 
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definition of disaster recovery mode is outside the scope of this standard. The ADC device server shall set the 
drmode bit to zero when the mandroff bit is set to zero and the DT device exits disaster recovery mode. 

A write protect (wp) bit set to one shall enable write protection (see the relevant RMC command standard). A wp bit 
set to zero shall disable this source of write protection. The wp bit shall be set to zero by the DT device each time a 
medium is unloaded. 

The current density field shall be set to the density code associated with the density in which the DT device is 
currently operating. The current density field shall be ignored by the DT device on MODE SELECT commands. 

The identification descriptors are the same as those in the Device Identification VPD page (see SPC-3). Only 
identification descriptors with the association field set to 00b (i.e., logical unit) shall be used. On MODE SELECT 
commands, if any identification descriptor contains an association field set to a value other than 00b, then the 
ADC device server shall return CHECK CONDITION status with the sense key to ILLEGAL REQUEST and the 
additional sense code set to INVALID FIELD IN PARAMETER LIST. 


6.2.2.3.3 SMC logical unit descriptor format 

The descriptor format for an SMC logical unit is defined in table 52. 


Table 52 — SMC logical unit descriptor format 


Bit 

Byte 

7 6 5 4 3 2 1 0 

0 

LOGICAL UNIT INDEX 

1 

DEVICE TYPE (08h) 

2 

(MSB) 

3 

ADDITIONAL DESCRIPTOR LENGTH (08h) 

(LSB) 

4 


5 

LOGICAL UNIT NUMBER 

6 

Reserved cache enable 

7 

Reserved 

8 

(MSB) 

9 

REMOTE SMC DEVICE SERVER LOGICAL UNIT NUMBER 

(LSB) 

10 


11 

Reserved 


The logical unit index field contains a value assigned by the DT device at power on that uniquely identifies the 
SMC logical unit from all other logical units on the DT device, independent of device server. This field shall not be 
changeable. The ADC device server shall terminate a MODE SELECT command that attempts to change the value 
in the logical unit index field with CHECK CONDITION status with the sense key to ILLEGAL REQUEST and the 
additional sense code set to INVALID FIELD IN PARAMETER LIST. 

The device type field shall contain the value shown in table 52 (i.e., 08h, a medium changer device (see SPC-3)). 

The additional descriptor length field contains the number of descriptor bytes that follow and shall be set to the 
value shown in table 52. 
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The logical unit number field specifies, for the SMC logical unit when accessed through the DT device primary 
port(s): 


a) the LUN if access controls are not in effect; or 

b) the default LUN if access controls are in effect (see SPC-3). 

The bridging manager shall use the value of the remote smc device server logical unit number field when 
addressing the automation device logical unit containing the remote SMC device server (see 4.3). 

The logical unit number field and the remote smc device server logical unit number field each contain the first 
two bytes (i.e., bytes 0 and 1) of a single level logical unit structure or the contents of a two byte extended logical 
unit address (see SAM-3). The logical unit number field and the remote smc device server logical unit 
number field shall be ignored if the enable bit is set to zero. The ADC device server shall return a CHECK 
CONDITION status with the sense key set to ILLEGAL REQUEST and the additional sense code set to INVALID 
FIELD IN PARAMETER LIST to a MODE SELECT command (see SPC-3) when multiple descriptors with the 
enable bit set to one that have the same value in the logical unit number field. 

A cache bit set to one and the enable bit set to one specifies that the local SMC device server may cache SMC 
data and status (see 4.3.5). If the ADC device server receives a MODE SELECT command with parameter data of 
the enable bit set to zero and the cache bit set to one, then the ADC device server shall return CHECK 
CONDITION status with the sense key set to ILLEGAL REQUEST and an additional sense code set to INVALID 
FIELD IN PARAMETER LIST. A cache bit set to zero or an enable bit set to zero specifies that the local SMC 
device server shall not cache SMC data and status. 

An enable bit set to one specifies that the DT device primary port(s) associated with the SMC logical unit shall be 
responsive to commands and task management requests received on the DT device primary port(s). Received 
commands may be processed by the local SMC device server or may be passed by the bridging manager to the 
remote SMC device server for processing (see 4.3). An enable bit set to zero specifies that the DT device primary 
port(s) associated with the SMC logical unit shall not respond to commands and task management requests 
received on the DT device primary port(s) and the associated SMC logical unit number shall not be included in the 
logical unit inventory (see SPC-3) for all l_T nexuses associated with a DT device primary port. The enable bit has 
no effect on the access to the SMC device server through the ADI port. 

If the enable bit is changed from one to zero, then the local SMC device server shall implicitly abort all commands 
in its task set and report CHECK CONDITION status with the sense key set to ABORTED COMMAND and the 
additional sense code set to LOGICAL UNIT COMMUNICATION FAILURE for each command. All remaining 
device servers (e.g., ADC device server, RMC device server) in the DT device shall report a change in the logical 
unit inventory (see SPC-3) to any application clients connected through a DT device primary port. 
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6.2.2.3.4 ADC logical unit descriptor format 

The descriptor format for an ADC logical unit is defined in table 53. 


Table 53 — ADC logical unit descriptor format 


Bit 

Byte 

7 6 5 4 3 2 1 0 

0 

LOGICAL UNIT INDEX 

1 

DEVICE TYPE (12h) 

2 

(MSB) 

3 

ADDITIONAL DESCRIPTOR LENGTH (04h) 

(LSB) 

4 


5 

LOGICAL UNIT NUMBER 

6 

Reserved enable 

7 

Reserved 


The logical unit index field contains a value assigned by the DT device at power on that uniquely identifies the 
ADC logical unit from all other logical units on the DT device, independent of device server. This field shall not be 
changeable. The ADC device server shall terminate a MODE SELECT command that attempts to change the value 
in the logical unit index field with CHECK CONDITION status with the sense key to ILLEGAL REQUEST and the 
additional sense code set to INVALID FIELD IN PARAMETER LIST. 

The device type field shall contain the value shown in table 53 (i.e., 12h, an Automation/Drive Interface device 
(see SPC-3)). 

The additional descriptor length field contains the number of descriptor bytes that follow and shall be set to the 
value shown in table 53. 

The logical unit number field specifies, for the ADC logical unit when accessed through the DT device primary 
port(s): 

a) the LUN if access controls are not in effect; or 

b) the default LUN if access controls are in effect (see SPC-3). 

The logical unit number field contains the first two bytes (i.e., bytes 0 and 1) of a single level logical unit structure 
or the contents of a two byte extended logical unit address (see SAM-3). The logical unit number field shall be 
ignored if the enable bit is set to zero. The ADC device server shall return a CHECK CONDITION status with the 
sense key set to ILLEGAL REQUEST and the additional sense code set to INVALID FIELD IN PARAMETER LIST 
to a MODE SELECT command (see SPC-3) when multiple descriptors with the enable bit set to one have the 
same value in the logical unit number field. 

An enable bit set to one specifies that the DT device primary port(s) associated with the ADC logical unit shall be 
responsive to commands and task management requests received on the DT device primary port(s). An enable bit 
set to zero specifies that the DT device primary port(s) associated with the ADC logical unit shall not respond to 
commands and task management requests received on that DT device primary port(s) and the associated ADC 
logical unit number shall not be included in the logical unit inventory (see SPC-3) for all l_T nexuses associated 
with a DT device primary port. The enable bit has no effect on the access to the ADC device server through the 
ADI port. 
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If the enable bit is changed from one to zero, then the ADC device server shall implicitly abort all commands in its 
task set received on a DT device primary port and report CHECK CONDITION status with the sense key set to 
ABORTED COMMAND and the additional sense code set to LOGICAL UNIT COMMUNICATION FAILURE for 
each command. All remaining device servers (e.g., local SMC device server, RMC device server) in the DT device 
shall report a change in the logical unit inventory (see SPC-3) to any application clients connected through a DT 
device primary port. The enable bit changing from one to zero shall have no effect on commands and task 
management requests received on an ADI port. 


6.2.2.4 Target Device Serial Number subpage 

The Target Device Serial Number subpage is variable-length and contains the product serial number of the RMC 
device server and the ADC device server that shall be reported via the Unit Serial Number VPD page (see SPC-3). 
This product serial number shall not affect the product serial number of the local SMC device server. The subpage 
is defined in table 54. 


Table 54 — Target Device Serial Number subpage 


Bit 

Byte 

7 

6 

5 

4 

3 

2 

1 

0 

0 

PS 

SPF (1b) 

PAGE CODE (OEh) 

1 

SUBPAGE CODE (04h) 

2 

Reserved 

3 

PAGE LENGTH (n-3) 

4 




Reserved 



MPSN 

5 




Reserved 





7 








8 









n 




rKUUUO 1 oEKIAL fMUIVlDEK 





See SPC-3 for a description of the ps bit, spf bit, page code field, subpage code field, and page length field. The 
spf bit, page code field, and subpage code field shall be set to the values shown in table 54. 
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The modify product serial number (mpsn) bit and product serial number field are used to modify and report 
modifications to the product serial number, as defined in table 55. 


Table 55 — mpsn field 


Code 

MODE SENSE command a 

MODE SELECT command a 

00b 

The mpsn field shall be set to zero for 
a MODE SENSE command. The 

PRODUCT SERIAL NUMBER field Shall 
contain the currently assigned value. 

Do not modify the product serial num¬ 
ber. The PRODUCT SERIAL NUMBER field 
shall be ignored. 

01b 

Invalid 

Reserved 

10b 

Set the product serial number to the 
manufacturer-assigned value. The 
PRODUCT SERIAL number field shall be 
ignored. 

11b 

Set the product serial number to the 
values in the product serial number 
field. 

a See SPC-3. 


See SPC-3 for a description of the product serial number field. An application client may change the product 
serial number as a means to change the RMC logical unit’s T10 vendor ID based identification descriptor (see 
SPC-3). 


6.3 Vital product data parameters 

6.3.1 Vital product data parameters overview and page codes 

This subclause defines the vital product data parameters (VPD) pages used with ADC device types. See SPC-3 for 
VPD pages used with all device types. The VPD page codes specific to ADC devices are specified in table 56. 


Table 56 — ADC device VPD page codes 


Page Code 

Description 

Support 

requirement 

Reference 

OOh 

01 h - 7Fh 

80h 

81h - 82h 

Supported VPD Pages 

Reserved 

Unit Serial Number 

Obsolete 

Mandatory 

Mandatory 

SPC-3 

SPC-3 

a See 6.3.2. 
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Table 56 — ADC device VPD page codes 


Page Code 

Description 

Support 

requirement 

Reference 

83h 

84 h 

85h 

86h 

87h 

88h 

89h - BOh 

Blh 

B2h - BFh 

COh-FFh 

Device Identification 

Software Interface Identification 

Management Network Addresses 

Extended INQUIRY Data 

Mode Page Policy 

SCSI Ports 

Reserved 

Manufacturer-assigned Serial Number VPD page 

Reserved 

Vendor specific 

Mandatory 

Optional 

Optional 

Optional 

Optional 

Optional 

Optional 

SPC-3 a 

SPC-3 

SPC-3 

SPC-3 

SPC-3 

SPC-3 

6.3.3 

a See 6.3.2. 


6.3.2 Device Identification VPD page 

The ADC device server shall either: 

a) not return the T10 vendor ID descriptor (see SPC-3) with an association field set to 00b (i.e., logical unit); 
or 

b) ensure that the T10 vendor ID descriptor with an association field set to 00b (i.e., logical unit) be unique 
(e.g., by including “ADC” within the vendor specific identifier field). 

6.3.3 Manufacturer-assigned Serial Number VPD page 

Table 57 defines the Manufacturer-assigned Serial Number VPD page. 


Table 57 — Manufacturer-assigned Serial Number VPD page 


Bit 

Byte 

7 6 5 

4 3 2 1 0 

0 

PERIPHERAL QUALIFIER 

PERIPHERAL DEVICE TYPE 

1 

PAGE CODE (Blh) 

2 

Reserved 

3 

PAGE LENGTH (n-3) 

4 


n 

MANUFACTURER SERIAL NUMBER 


See SPC-3 for a description of the peripheral qualifier field, peripheral device type field, page code field, and 
page length field. The page code field shall be set to the value shown in table 57. 

The manufacturer-assigned serial number field contains right-aligned ASCII data (see SPC-3) that is the 
manufacturer-assigned serial number. If the manufacturer-assigned serial number is not available, then the ADC 
device server shall return ASCII spaces (20h) in this field. If the manufacturer-assigned serial number differs from 
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the value in the product serial number field (see SPC-3), then the manufacturer-assigned serial number shall not 
be used in building the T10 vendor ID descriptor (see SPC-3). 
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